Chat Design Document

I. Essentials

• User directory: /chat/
• TCL procedures: /tcl/chat-procs.tcl
• Requirements document: /doc/chat/requirements.html
• Data model: chat-create.sql

II. Introduction

• We want to allow our users to participate in instant message communications with other community members.
• We want our system to be integrated.
• We want to use our own internal permissioning system to more securely determine who can enter, create or delete rooms that would be possible using an external security system.
• We want something that can be extended and maintained by any ArsDigita programmer, i.e., something that requires only AOLserver, Tcl, Oracle, and Java skills.
• Commercial chat servers tend to be expensive to maintain and will require a separate community data model.

III. Historical Considerations

IV. Competitive Analysis

AOL Instant Messenger (AIM)

Yahoo Chat

DigiChat

The ArsDigita Java Chat application does not have a pretty client interface, nor does it support text formatting 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.

V. Design Tradeoffs

Archive or not?

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.

HTML vs. Applet

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.

Java Servlet vs. Pure AOL server

• reduced development time,
• a large number of API provided by SUN, and
• portability,

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.

Chat message protocol: Text base vs. Java serialize object

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.

Chat messages are stored in cache

VI. API

Chat message XML definition

<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>

API

All chat functionalities accessible 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.

VII. Data Model Discussion

Should chat messages constitute a subtype of acs-object?

VIII. User Interface

Types of chat we need to support

• Public chat rooms. These are open to everyone in the users_active view.
• Private chat rooms. These are open to people in particular user parties. We check permissions using permissioning for each room.

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.

Options for the publisher

• Is a room private?
• If so, grant permission to a particular party to enter the room?
• Is a room moderated?
• If so, by whom?
• Should we archive all chat messages in this room?
• Is this room active?

Options for room administrator

• If this room archives all of its messages, then give a 'create transcript' option.
• View available transcripts.
• Edit/delete existing transcripts.

Why the HTML version can't autorefresh

IX. Configuration/Parameters

• AppletHeight - Height of display Java applet.
• AppletWidth - Width of display Java applet.
• ServerPort - Port will be listen for Java client connection.

X. Future Improvements/Areas of Likely Change

XI. Authors

• System creator:
• 3.x:Aurelius Prochazka
• 3.4:Stefan Deusch
• 4.x:David Dao
• System owner:
• David Dao
• Documentation authors:
• 3.x:Philip Greenspun
• 4.x:David Dao and Joshua Finkler

XII. Revision History