Index: openacs-4/packages/chat/www/doc/design.html =================================================================== RCS file: /usr/local/cvsroot/openacs-4/packages/chat/www/doc/design.html,v diff -u -r1.3.2.2 -r1.3.2.3 --- openacs-4/packages/chat/www/doc/design.html 24 Nov 2019 11:06:22 -0000 1.3.2.2 +++ openacs-4/packages/chat/www/doc/design.html 3 Nov 2023 15:37:44 -0000 1.3.2.3 @@ -46,9 +46,9 @@ 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.
    • +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 @@ -66,8 +66,15 @@

    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)

    + +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 @@ -77,13 +84,15 @@ has a logging option, thus there is no way for a site to offer a chat transcript to its members.

    -Yahoo Chat

    + +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 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 @@ -123,224 +132,25 @@ 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

    -An advantage to using an HTML client as opposed to an applet-based client -is the ability to have rich graphical representations as a part of the -chat, such as color formatting, in-line images rendered by the browser in -use, et cetera.  Furthermore, users who are still using older non-Java -enabled browsers will be able to participate in the chat.  A limitation -of the HTML client is that users cannot see messages in real time, as HTML -provides no auto-update functionality. -

    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

    -Use of a Java servlet provides us with - -however using a servlet requires a somewhat nonstandard (for ACS, that -is) installation method for the chat package, since the application -requires Jakarta-tomcat and -nstomcat to be preinstalled and configure properly. These extra steps -are dificult and different on each platform. - -

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

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

    -

    Chat message XML definition

    -
    
-<login>
-
-   <user_id></user_id>
-
-   <user_name></user_name>
-
-   <pw></pw>
-
-   <room_id></room_id>
-
-</login>
-
-
    After connection to the chat server, each client must -identify itself via a login message. The chat server will disconnect -the client if the first message is not a proper login message or if the user -doesn't have proper permissions for the chat room. - -
    
-<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>
-
-
    - -To construct a public message that will broadcast to everyone in the -chat room, the to_user_id and to fields -need to be excluded from the message. When these two fields are present in -the message then the message will only send to a specific -user. Sending private messages to HTML users is not yet supported. - -
    
-<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>
-
-
    - -Each time a client enters or exits the room, an appropriate message -will be broadcast to all clients in the chat room notifying them of a -change in the chat user list. - -
    
-<system>
-
-   <userlist>
-
-      <user>
-
-         <user_id></user_id>
-
-         <user_name></user_name>
-
-      </user>
-
-      <user>
-
-         <user_id></user_id>
-
-         <user_name></user_name>
-
-      </user>
-
-      ...
-      ...
-   </userlist>
-
-</system>
-
-
    After the Java applet client has successfully logged -into the chat room, a list of users currently in the room will be sent -our from the server. - -

    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

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

    -VIII. User Interface

    +VII. User Interface

    Types of chat we need to support

    @@ -405,34 +215,11 @@ Edit/delete existing transcripts.
    • -

    -Why the HTML version can't autorefresh

    -The HTML page cannot have a Refresh header to force a redraw of the page; -if it did, the user would be at risk of losing what he or she was typing -into the post form.

    -IX. Configuration/Parameters

    +VIII. Authors - -

    -X. Future Improvements/Areas of Likely Change

    -A much more stable Applet client interface would be in order. It would -also be nice if we allowed more concurrent applet connections to the server. -

    -XI. Authors

    - -