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 have our own chat server because:

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 OpenACS programmer, i.e., with as few external dependencies as possible.
Commercial chat servers tend to be expensive to maintain and will require a separate community data model.

III. Historical Considerations

Chat applications allow inexpensive and efficient social interactions between community members spread across the globe. A community can use the Chat application to allow its members to have an interactive session with a special guest or a community member through the means of a moderated chat. A customer support site can use the Chat application to offer instant responses to its customers regarding its products.

IV. Competitive Analysis

Note: this section was produced at the time when the chat package was first implemented and refers to products that are no longer in service.

AOL Instant Messenger (AIM)

So why can't companies that want to do 1:1 conversations just use AIM? AOL Instant Messenger works best with some additional software to be installed on the user's machine. This is free software, is shipped with Netscape 4.x, and is certainly available to AOL service customers. But it is not universal and you can't be guaranteed that when someone is connecting to your Web site they have the AIM client. Furthermore, AIM doesn't has a logging option, thus there is no way for a site to offer a chat transcript to its members.

Yahoo Chat

Yahoo offers its members a wide range of services including chat. Their chat supports both HTML and Java applet clients. Unfortunately, their chat software is proprietary, so companies cannot incorporate their community model with Yahoo's chat software.

DigiChat

DigiChat is a standalone Java chat application. It offers a well thought out chat client interface and also supports moderated chats. However, like most third party applications, there are no easy means by which Digichat can be integrated with a site's preexisting user data model. DigiChat also comes with a heavy price tag, and as such it might not be suitable for a small communities that need to support chat sessions.

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?

We have to drive the entire system design from a publishing decision: are we interested in seeing archives of chat sessions? If we are, then archiving into a single table makes a lot of sense. We can perform a single SQL query to see everything that a user has contributed. We can perform a single SQL query to see how a customer service person is doing. And so on.

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.

Chat messages are stored in cache

Since we do not allow a user to view messages prior to his entrance into the chat room, there is no need for time-consuming Oracle queries to retrieve messages. Storing messages in the server cache keeps us from being able to archive all of the messages from the time the server started. I decided that I would limit the number of messages cached per room.

VI. Data Model Discussion

Should chat messages constitute a subtype of acs-object?

We are not implementing individual permissioning on each chat message. As a result we can avoid unnecessary complexity of subtyping the chat message type. Chat messages will have their own table.

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

For either kind of chat room, we should support moderated chat. That is, in such a scenario a posting doesn't go live until it has been approved by someone who has the 'chat_room_moderate' privilege in the 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

Some options are configurable per-room, e.g.,

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.

VIII. Authors

System creator:

Documentation authors:

3.x:Philip Greenspun
4.x:David Dao and Joshua Finkler

IX. Revision History

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
1.0	Cleanup of outdated information, in particular about the discontinued Java implementation	03/11/2023	Antonio Pisano