The ArsDigita Java Chat application does not have a pretty client interface, -nor does it support text formating like Yahoo and Digichat. However, -our Chat application is open source. As such, any competent Java -developer will be able to improve the interface based upon their or their -employer's preferences. Using the ArsDigita Chat application allows site -developers access to a rich community data model which is compatible with -a variety of existing open-source applications. -
A disadvantage of archiving is that it chews up disk space. Imagine -for a moment that your service is the size of America Online, wherein one -million subscribers chat or use AIM every day. Imagine also that -each person types 50 rows of chat/AIM content each of which requires 100 -bytes of storage. Such a scenario would require our table to -grow by 50 million rows and 5 GB each day. After 20 days, we would begin -to bump up against the billion-row table size that data warehouse experts -suggest as a practical limit. -
So it seems that on popular public sites we won't be able to store everything -that users type. At the same time, a customer's interaction with a customer -service person, or a special guest chat should be archived. Also, -many sites engage considerably less traffic than does AOL, and these sites -may benefit from being able to log all chat/AIM communications. -
The solution we came up with was to provide an option that allows the -creator of a room to decide whether or not to archive the messages. -
By using a Java applet-based client, users can see messages updated -in real time. This is important in, e.g., a customer service setting. -Since SUN JDK 1.1 doesn't provides a text rendering API, applet-based clients -are limited in the format of the text that they can display. There are -also limitations on the server as to how many TCP sockets can be open at -the same time. Since each user using an applet-based chat client -will use one TCP socket, there could be a limit on how many user can use -the applet. This problem could be solved by employing customized hardware -more suitable for the task. -
Our system provides both a HTML and a Java applet-based chat client. -By providing each of these, we open up our Chat application to a broader -pool of users by offering users the chat method which will work best for -them. -
Using the AOL server socket API, there could be a performance -improvement and will not require installation of Jakarta-tomcat. -Unfortunately, AOL does not provide much by way of documentation -regarding AOL socket. As of the current time, there are still major -features missing from the AOL socket API which would be required to -completely replace the Java/servlet method. - -
Initially, I chose using a Java servlet as my development platform -due to time constraints. As development progressed, I analyzed the use -of the servlet in the current chat application. Since the servlets -sole purpose is to provide communication between the HTML and the Java -applet clients, I concluded that this would be adequate for the present -purposes, and that the extra efforts required to set up Jakarta-tomcat -with AOL server would be unjustified. After some experimentation, I -was able to rebuild the bridge between the HTML and the Java applet -clients using only AOL Server and the Java chat server. As a resul,t the Chat -application may now be downloaded and installed just as any other ACS 4 -applications may be. - -
In the earlier chat version, chat messages were broadcast to the -applet client Java serialize objects. The advantage of serialize -objects is that they make it easy to retrieve information. The -disadvantage of this method is the messages are limited to Java only. - -
To support clients from different programming language and not -limit our application to Java, I choose an XML text base for the chat -message protocol. - -
-<login>
-
- <user_id></user_id>
-
- <user_name></user_name>
-
- <pw></pw>
-
- <room_id></room_id>
-
-</login>
-
-
-<message>
-
- <message_id></message_id>
-
- <from_user_id></from_user_id>
-
- <from></from>
-
- <to_user_id></to_user_id>
-
- <to></to>
-
- <room_id></room_id>
-
- <status>approved | pending</status>
-
- <body></body>
-
-</message>
-
-
-<system>
-
- <user_enter>
-
- <user_id></user_id>
-
- <user_name></user_name>
-
- </user_enter>
-
-</system>
-
-
-<system>
-
- <user_leave>
-
- <user_id></user_id>
-
- <user_name></user_name>
-
- </user_leave>
-
-</system>
-
-
-<system>
-
- <userlist>
-
- <user>
-
- <user_id></user_id>
-
- <user_name></user_name>
-
- </user>
-
- <user>
-
- <user_id></user_id>
-
- <user_name></user_name>
-
- </user>
-
- ...
- ...
- </userlist>
-
-</system>
-
-All chat functionalities accessable from the browser are available -as an API. Providing these API allows different applications to modify -chat without an application-specific user interface. These -API will throw errors if their corresponding PL/SQL statement fail, so -all applications employing them need to 'catch error' to display a -nice error message to the user.
chat_message_post -- This API inserts chat message to the database depend whether a chat -room archive mode. It is also broadcast the message to all Java -clients in the room. - -
chat_message_retrieve -- This API is only used by the HTML client, and is used each time the HTML -client refreshes. The API does not require database call, messages will be retrieve -from AOL Server cache. -
We want to support one-to-one messages for customer support, so we need -one layer on top of the Chat application to make sure that users can find -an appropriate chat partner. For example, if Bill User says that he needs -support for his Acme widget, the system has to find the least busy authorized -Acme widget support person and start a one-to-one chat session between -Bill and that person. -
For public community sites where nothing is being sold or supported, -a publisher might wish to limit the load on the server from all of this -one-to-one chatting. -
| Document Revision # | - -Action Taken, Notes | - -When? | - -By Whom? | -
|---|---|---|---|
| 0.1 | - -Revision from chat 3.4 design document | - -11/17/2000 | - -David Dao | -
| 0.2 | - -Editing and augmentation | - - -11/18/2000 | - -David Dao and Josh Finkler | -
| 0.3 | - -Editing | - -12/04/2000 | - -David Dao | -
| 0.4 | -Editing | - -12/05/2000 | -Josh Finkler | -
| 0.5 | -Revision for beta version | -01/11/2001 | -David Dao | -
-
The ArsDigita Java Chat application does not have a pretty client interface, +nor does it support text formating like Yahoo and Digichat. However, +our Chat application is open source. As such, any competent Java +developer will be able to improve the interface based upon their or their +employer's preferences. Using the ArsDigita Chat application allows site +developers access to a rich community data model which is compatible with +a variety of existing open-source applications. +
A disadvantage of archiving is that it chews up disk space. Imagine +for a moment that your service is the size of America Online, wherein one +million subscribers chat or use AIM every day. Imagine also that +each person types 50 rows of chat/AIM content each of which requires 100 +bytes of storage. Such a scenario would require our table to +grow by 50 million rows and 5 GB each day. After 20 days, we would begin +to bump up against the billion-row table size that data warehouse experts +suggest as a practical limit. +
So it seems that on popular public sites we won't be able to store everything +that users type. At the same time, a customer's interaction with a customer +service person, or a special guest chat should be archived. Also, +many sites engage considerably less traffic than does AOL, and these sites +may benefit from being able to log all chat/AIM communications. +
The solution we came up with was to provide an option that allows the +creator of a room to decide whether or not to archive the messages. +
By using a Java applet-based client, users can see messages updated +in real time. This is important in, e.g., a customer service setting. +Since SUN JDK 1.1 doesn't provides a text rendering API, applet-based clients +are limited in the format of the text that they can display. There are +also limitations on the server as to how many TCP sockets can be open at +the same time. Since each user using an applet-based chat client +will use one TCP socket, there could be a limit on how many user can use +the applet. This problem could be solved by employing customized hardware +more suitable for the task. +
Our system provides both a HTML and a Java applet-based chat client. +By providing each of these, we open up our Chat application to a broader +pool of users by offering users the chat method which will work best for +them. +
Using the AOL server socket API, there could be a performance +improvement and will not require installation of Jakarta-tomcat. +Unfortunately, AOL does not provide much by way of documentation +regarding AOL socket. As of the current time, there are still major +features missing from the AOL socket API which would be required to +completely replace the Java/servlet method. + +
Initially, I chose using a Java servlet as my development platform +due to time constraints. As development progressed, I analyzed the use +of the servlet in the current chat application. Since the servlets +sole purpose is to provide communication between the HTML and the Java +applet clients, I concluded that this would be adequate for the present +purposes, and that the extra efforts required to set up Jakarta-tomcat +with AOL server would be unjustified. After some experimentation, I +was able to rebuild the bridge between the HTML and the Java applet +clients using only AOL Server and the Java chat server. As a resul,t the Chat +application may now be downloaded and installed just as any other ACS 4 +applications may be. + +
In the earlier chat version, chat messages were broadcast to the +applet client Java serialize objects. The advantage of serialize +objects is that they make it easy to retrieve information. The +disadvantage of this method is the messages are limited to Java only. + +
To support clients from different programming language and not +limit our application to Java, I choose an XML text base for the chat +message protocol. + +
+<login>
+
+ <user_id></user_id>
+
+ <user_name></user_name>
+
+ <pw></pw>
+
+ <room_id></room_id>
+
+</login>
+
+
+<message>
+
+ <message_id></message_id>
+
+ <from_user_id></from_user_id>
+
+ <from></from>
+
+ <to_user_id></to_user_id>
+
+ <to></to>
+
+ <room_id></room_id>
+
+ <status>approved | pending</status>
+
+ <body></body>
+
+</message>
+
+
+<system>
+
+ <user_enter>
+
+ <user_id></user_id>
+
+ <user_name></user_name>
+
+ </user_enter>
+
+</system>
+
+
+<system>
+
+ <user_leave>
+
+ <user_id></user_id>
+
+ <user_name></user_name>
+
+ </user_leave>
+
+</system>
+
+
+<system>
+
+ <userlist>
+
+ <user>
+
+ <user_id></user_id>
+
+ <user_name></user_name>
+
+ </user>
+
+ <user>
+
+ <user_id></user_id>
+
+ <user_name></user_name>
+
+ </user>
+
+ ...
+ ...
+ </userlist>
+
+</system>
+
+All chat functionalities accessable from the browser are available +as an API. Providing these API allows different applications to modify +chat without an application-specific user interface. These +API will throw errors if their corresponding PL/SQL statement fail, so +all applications employing them need to 'catch error' to display a +nice error message to the user.
chat_message_post +- This API inserts chat message to the database depend whether a chat +room archive mode. It is also broadcast the message to all Java +clients in the room. + +
chat_message_retrieve +- This API is only used by the HTML client, and is used each time the HTML +client refreshes. The API does not require database call, messages will be retrieve +from AOL Server cache. +
We want to support one-to-one messages for customer support, so we need +one layer on top of the Chat application to make sure that users can find +an appropriate chat partner. For example, if Bill User says that he needs +support for his Acme widget, the system has to find the least busy authorized +Acme widget support person and start a one-to-one chat session between +Bill and that person. +
For public community sites where nothing is being sold or supported, +a publisher might wish to limit the load on the server from all of this +one-to-one chatting. +
| Document Revision # | + +Action Taken, Notes | + +When? | + +By Whom? | +
|---|---|---|---|
| 0.1 | + +Revision from chat 3.4 design document | + +11/17/2000 | + +David Dao | +
| 0.2 | + +Editing and augmentation | + + +11/18/2000 | + +David Dao and Josh Finkler | +
| 0.3 | + +Editing | + +12/04/2000 | + +David Dao | +
| 0.4 | +Editing | + +12/05/2000 | +Josh Finkler | +
| 0.5 | +Revision for beta version | +01/11/2001 | +David Dao | +
+