|
|
|
|
|
|
|
|
by Bradley Birnbaum
Everyday, people are finding new ways to push the envelope of the uses for the World Wide Web. Being a developer of WWW applications I've frequently been asked if there was a way to make a usable chat application on the Web that would resemble the chat rooms of the popular on-line services. Using Netscape's Client-Pull technology and a little ingenuity from the people at Interactive Marketing Services, we were able to put together an application that adds a new dimension to the Web....the ability to chat, at http://www.vyp.com/chat/index.html
During the planning phase of the development, the primary goal was to provide a feature-rich, easy-to-use application that would resemble chat rooms that many people commonly frequent in on-line services. There were several design issues that had to be considered early on in the project. The primary issue was that, being the World Wide Web, chatting would naturally be different from a real-time chat application because of the limitations of the Web. The text can't appear in real-time so another solution had to be found. The solution was Netscape's Client-Pull technology.
Client-Pull only works with the Netscape Navigator, version 1.1 or newer. However, if you did choose to use another browser, everything will still work except the automatic screen updates. The screen is updated when you send a message or change rooms, meaning the update rate will be satisfactory even with a non-Netscape browser.
The Chat Application provides the users with a variety of public rooms--including ``Free For All'' which allows the messages to contain embedded HTML tags. Users can also have personal conversations in Private Rooms, if they prefer, by entering a room with the name of their choice. This approach allows for an unlimited number of simultaneous Private Rooms--the only requirement is that users know the name of the Private Room where the people they want to talk to are located. There is no limit to the number of people a Private Room can have, which is convenient for having large conversations.
One enhancement came about as a result of the Private Rooms--the ability to send a private message to a user no matter what room they occupy. This becomes very useful when a user would like to invite another user into a Private Room. This way user A can send a private message to user B telling them the name of the Private Room to enter. Prior to this people would tell each other the name of the Private Room to enter with a message to a public room, which defeats the purpose of Private Rooms.
It is quite simple to send a private message to many users, ranging from only one to everyone on the Chat Room. All one needs to do is select the user(s) in the listbox and hit the ``Send Private Message'' button, which will then refresh the screen. Upon being refreshed, the screen displays the user(s) the message is for and presents a text box for the contents of the private message. Once sent, the message will appear towards the top of the recipient's screen upon their next screen refresh.
Another important feature that adds ease of interaction is a list of current users, including the room where they can be found. This was introduced into the software because of the overwhelming number of requests for this feature from users in the early stages. User feedback was very significant in shaping the feature set of the chat software.
There were a variety of challenges while planning the IMS
(Interactive Marketing Services) Chat Room. First, the state needed
to be preserved across screen calls. Pertinent information, such as
the username, screen length, refresh rate, current room, and
background settings needs to be preserved across screen refreshes.
This is accomplished by means of using both the GET and
POST methods. While unorthodox, it was necessary to
accomplish this feat. When users enter information, the POST
method is used. However, when the screen is automatically refreshed
using client-pull the GET method must be used--client-pull
simply requests a URL, so all pertinent information needs to be passed
on within the URL. The following line indicates how the refresh line
is embedded within the HTML document to automatically call the ``run''
script with the appropriate data variables:
<META HTTP-EQUIV="Refresh" CONTENT="15;URL=http://www.vyp.com/cgi-bin/chat /run?user=Brad&rate=15&len=5&room=New+Users&back=on">
When the script ``run'' is executed, it parses data from the
environmental variable QUERY_STRING as well as reading x
number of characters from standard input (where x is the environmental
variable CONTENT_LENGTH). Any information that is obtained
from STDIN is considered ``newer'' than the information passed within
the URL, and will replace it.
Passing the data through CGI via both the POST and
GET method also has another key advantage: it enables the
``run'' script to easily determine if the user has changed rooms. If
so, it can send the appropriate announcement to the room the user left
(``User has left New Users and Joined Private Room'') and an
announcement to the new room (``User has entered Private Room''). This
is accomplished by simply comparing the room values of both URLs.
There are several user definable settings the system must deal with:
These settings provide an environment that will be optimal for the user. Screen length was made user definable because people have different resolutions on their screens; some users can fit more text on their screen than others. The screen length setting can also be used to view prior lines in the conversation that might have been missed. The refresh rate setting defaults to 15 seconds but can be made slower. Users with slow connections may wish to decrease the refresh rate in order to avoid constant connections. Refresh rate can't be set to a value less than 15, since anything faster might not give the user ample time to read the screen or make their selection. The background setting defaults to ``on'', but after some testing it was determined that some users preferred, for efficiency and screen clarity, not to have a background. Thus, we provided them with an option.
The application stores each room's conversations in a separate file. Every new message or announcement is appended to the end of the appropriate file. In order to distinguish private rooms from public rooms, private room names always begin with an underscore. This is done transparently within the software so it looks like a normal room name to the user. Private room files are stored in a separate directory for easy file maintenance. In addition, all room names that contain spaces have their spaces translated to plus signs, as space would cause words in the name to be interpreted as multiple arguments. The plus signs are converted back to spaces when the room name is displayed back to the user.
Private messages need to be handled differently, since there can be private messages to more than one user. CGI sets each of the selected names in the listbox to the same variable, therefore it is the responsibility of the program to treat the listbox variable differently. The program concatenates all the variables together while separating them by a series of characters. When a private message is sent, the software parses the private messages into an array for each user. It places the contents of the private message into a MESSAGES directory with a file name for the intended user. Every time the screen updates, it checks to see if there is a message for that user and, if so, prints it to the screen and deletes the message file so it won't be displayed again.
In addition to the ``run'' application, there is the ``server'' application which is responsible for housekeeping on the system. It runs constantly but sleeps every 5 seconds to reduce the load on the system. The responsibilities of the server application include file truncation, old message deletion, old private room deletion and truncation and, most importantly, the people list. There are three files associated with maintaining the current user count and user list. The PEOPLE file is constantly being appended with the current user, the time, and their location. This file grows very rapidly and is truncated to 1000 lines every 60 seconds. There is an entry appended to this file every time the a user refreshes their screen.
In addition to the PEOPLE file there are two other files containing current information. The NUM_PEOPLE file is a text file which simply contains the total number of people seen on the chat line within the last 60 seconds. This file is updated every 5 seconds and is read in by the run application. The CURRENT_PEOPLE file is a text file that is formatted in HTML and contains information about the people that were seen on the chat line in the last 60 seconds. The data is formatted as an HTML listbox and is inserted when the run application is executed.
The ``server'' application was used to speed up the chat line. Prior to its use, the ``run'' script was forced to calculate the current users. This task ended up being executed many more times than necessary since it really only needs to be done every 5 seconds. It addition, by having the ``server'' application truncate files, there is less data to process, and this, performance is increased.
The IMS Chat Line was initially written to provide a service to the Internet Community, as well as generate traffic at our site. Within the first month of its beta test, there was an average of 60 people using the chat room at any given time. It was a welcome addition to the WWW and I hope it continues to become more widely used.
Bradley Birnbaum is the Manager of Technical Development at Interactive Marketing Services in Hauppauge, NY. He specializes in Internet Applications that make creative use of the Web. In addition, he has been writing database applications in FoxPro for the past 4 years. He can be reached at bbirnbau@imsworld.com or Interactive Marketing Services, 180 Oser Ave, Hauppauge, NY, 11788, (516)273-2300
