by Greg Knauss
As more people make their way online, they invariably seek each other out, as people have throughout time. Reading someone's home page can be a nice diversion, but actually interacting with that person-the human being, not just preprogrammed scripts-offers one of the most attractive and interesting extensions to the Web.
Chat pages make this interaction possible. Instead of a barren, empty site, a chat page can add life, and allow instant, world-wide discussion of any subject imaginable.
Chat, in one form or another, has been a feature of computer networks for decades. On even the earliest systems, users could send messages back and forth to each other. In the early 1980s, CompuServe added the CB Simulator to their array of services and enabled worldwide chatting between hundreds of people at a time. Other commercial online services soon followed with similar features. Internet Relay Chat (IRC) and Multi-User Dimensions (MUDs) have been available on the Internet for several years.
Before the Web, though, chatting with other computer users often required either obscure knowledge or a subscription to a commercial service. Learning the intricacies of IRC or MUDs, or signing up to CompuServe or America Online, was more trouble than most people were willing to bother with.
But with a Web-based chat page, you simply type in the URL of the page you're interested in and you're there. After the page loads, you'll probably have to enter an alias (which can either be your real name or something more creative), but that's it. You and your newfound friends are ready to talk.
On most chat pages, you find out who else is present by clicking a button or by scrolling to the bottom of the page where a current list is kept. You click another button to send a message that you've typed into a text box on the chat page. If you want to send a picture of yourself with your messages, you enter the URL where your picture can be found. It's fun! Chat pages are often an instant success wherever they're installed.
But chat is a lot more than fun and games. Having a chat feature can be an important part of building an excellent Web site, and can become an important part of your business strategy. Chat allows for the following:
Expect to see these and other uses increase in variety and importance over time. Chat can be useful as well as fun.
Finding chat pages on the Web is easy-just do a Yahoo search on
the word "chat," and you get dozens of hits. While some
of them are IRC servers or hosts, many are interactive chat pages,
several good examples of which are listed in Table 40.1.
| Name | URL |
| WebChat Broadcasting System | http://wbs.net |
| ESPNET's SportsZone | http://espnet.sportszone.com/editors/talk |
| Cybersight | http://cybersight.com/cgi-bin/cs/ch/chat |
| HotWired's talk.com | http://www.talk.com |
| MTV's Tikkiland | http://mtv.com/tikkiland |
Try the pages shown in Table 40.1 to get a better idea of the way chat pages work. Most of them are based on forms, but some require Java or a helper application, which will be covered in more detail later in the chapter.
After you've experienced chat, you may want to add a chat service to your own Web site. Let's get some background first.
Web-based chat pages are all fairly similar and fairly simple. They all work off the same basic principle: delivering changes made to a database of user-entered information to each user individually. No matter how many frills are added, or how many bells and whistles are stuck on, every chat page shares that function.
When a user connects to a chat page, he is shown some of the conversation currently taking place-a few of the previously entered messages perhaps-and is offered space to make his own entry.
After typing some text, the user submits it to the chat server by pressing a button, and the server-either continually or in one big lump-responds with all the text entered by other chatters, the user's message appended to the bottom. When someone else enters a comment, the first user's text is among the many messages shown to him.
It's as simple as that. Figure 40.1 is an example.
Of course, almost anything appears simple at first blush and with only the basics discussed. There is almost an infinite number of variations to the chat theme, each providing a convenience or feature to attract more and more users. For a larger discussion of chat possibilities, see the later section "Power Chat Features."
Though Web chat servers have classically been CGI scripts, advances made in other forms of Web technology over the past year have made other, and in some ways better, methods possible.
Java, helper applications, Telnet, ActiveX, and Netscape plug-ins all allow chatting through the Web, for instance. And while CGI scripts are still popular tools (because they run solely on the server side and therefore work with almost every browser available), these newer technologies offer several possibilities that make them especially attractive for chatting.
CGI is transaction-based. In other words, interaction with the server is done in big chunks, with no updates made to the conversation until the user submits his comments. When this happens, the server then responds with all the comments made since his last update, as shown in Figure 40.2.
With client-side technologies like Java, helper applications, Telnet, ActiveX, and Netscape plug-ins, chat becomes streaming. This means that comments are continuously added to the conversation, even if the user never submits any messages himself. New input is constantly being displayed, even without any interaction. This makes Web chat much more like traditional computer chat, such as IRC or the chat rooms on commercial services (see Figure 40.3).
While streaming chat is more intuitive and flexible than transaction-based chat, it has the disadvantage of requiring more of the user. He must have the appropriate client-side software to run such a session, depending on what kind of chat server is being run. A Java chat requires a Java-capable browser, like Netscape 2.0 or higher, or Internet Explorer 3.0 or higher. An ActiveX chat requires Internet Explorer. These requirements can exclude anyone who does not have access to this software, like those using the text-based Lynx or the free Mosaic.
So you must carefully consider the advantages and disadvantages of each type of chat server before you consider installing one on your Web site. Do you want to include everyone who might come by, at the cost of transaction-based chatting? Or would you rather have a more natural interface, but exclude certain people from the conversation?
Such decisions are similar to the decisions you must make when deciding what level of HTML to support on your site. If you use Netscape-specific HTML tags, you may as well install a Java-based chat server, as Lynx and Mosaic users are already unable to view your pages. If you've taken care to stick to standard HTML, then a CGI-based chat server might be the way to go.
A CGI-based chat server is like any other CGI script. It's installed in your Web site's CGI-BIN directory and is run when people click a link to it.
A CGI-based chat server differs from many other CGI scripts, though, in that it must maintain data between invocations. While other simple CGI programs may have all the information they need provided by the user or available on the disk, chat servers must be capable of storing on-going conversations and recalling them the next time they are run, which might be just moments later.
This persistence of data can be accomplished in any of several ways, but the simplest is to just spool the user input to a disk for later recall.
Let's say a user enters a CGI-based chat area for the first time by clicking a link somewhere. There are no FORM arguments passed to the CGI script that is run, so the script can safely assume that the user is just entering the conversation. The script, at this point, might welcome the user, show him some context of the on-going conversation, and ask him for his input by using HTML FORMs. The CGI program might also include a HIDDEN field in the FORM, reminding itself which was the last message this user has seen.
When the user SUBMITs his message, the script runs again, but this time it knows that the user is participating in the conversation because arguments are passed-his comments, and some form of ID of the last message he saw. Now the script opens up the spool file on the disk, adds the user's message, then backtracks and writes out all the messages that have appeared in the file since the user last saw it. At the bottom of this response, the script adds another space for the user to type some more, and includes another HIDDEN field, storing the ID of the last message this time. Such output might look like Figure 40.4.
Figure 40.4 : A very simple CGI-based chat server might look like this.
This series can repeat forever, with any number of users running the same CGI script. Users can carry on a conversation because they continually see other users' comments whenever their screens are updated.
Listing 40.1 is pseudo-code for a transaction-based chat server.
Listing 40.1 Pseudo-Code of a Simple CGI-Based Chat Server
Set SPOOL_START to 0.
Get FORM arguments.
Any?
Yes, add USER_MESSAGE argument to end of spool file. Set SPOOL_START
to USER_LAST argument.
Send HTTP header.
Go to SPOOL_START in spool file, send to user's message.
Send input form, include USER_MESSAGE input field and USER_LAST hidden field
(set to the last message sent from spool file.)
Exit.
Obviously, there are enhancements that can be made to this script, even changes that should be made. For instance, as is, the spool file will grow forever. While storing conversations for future reference is nice, to let a file grow unchecked can easily fill up a file system and cause the program to crash. Ideally, the script would check for when the spool file passes a certain size and shrink it down, chopping off the oldest comments.
Also, it would be nice if the script asked each user for an alias
or name when he entered messages. That would make keeping track
of who a particular input is from much easier.
| CAUTION |
As with any file that has the potential to be accessed by several people at the same time, your chat server should take care when adding to the spool file. The traditional way to handle this situation is with a file lock, so that when one instance of your chat program is adding to the file, any others must wait for it to finish before adding to it themselves. It's important to remember that a Web server can run a CGI script several times simultaneously |
While the end result of a chat performed through a CGI server and a Java applet might be the same-people communicating with each other-the technical details are quite different.
CGI chat servers are completely server-side programs. All the code that handles the chat is run on the Web server, while the browser displays what it considers to be standard Web pages.
With Java, code is executed on both the client and server sides. When you click a link to a Java chat program, the client side is downloaded to your Web browser and run. It then connects to special code running on your Web server.
The advantage this has over CGI is subtle but important. In a way, Java has modified the way your browser works, so it can be much more flexible in how it deals with the chat session. Most Java chat programs, for instance, keep the connection with the server open at all times, and run a separate thread to constantly retrieve data, whether the user does anything or not. While CGI scripts must process conversations in hunks-that's just the way browsers work-Java programs can do whatever they please, including maintain a link with the server.
The downside of this flexibility is often more work for the programmer. Instead of a simple CGI program, both a client and a server must be written. Also, the issues involved with communication become more complicated, because the programmer can no longer rely on the Web server to handle it all for him. Despite all of this, the design of a Java-based solution is often more elegant.
Listing 40.2 is pseudo-code for a Java-based chat client.
Listing 40.2 Pseudo-Code for a Java-Based Chat Client
Connect to server on pre-defined port.
Set up screen, with large output area and one line input area.
Thread 1
Any messages waiting from server?
Yes, read them and print them in output area.
Loop on Thread 1
Thread 2
Is user message ready?
Yes, send it to the server.
Loop on Thread 2
Listing 40.3 is pseudo-code for a Java chat server. This part of the chat system can be written in Java or any other language. Because it does not need to run in browsers, it can be coded in anything that can handle network connections.
Listing 40.3 Pseudo-Code for a Chat Server
Start listening to pre-defined port.
Forever
Any connection?
Yes, announce that a user has logged on.
Any disconnections?
Yes, announce that a user has logged off.
Any messages?
Yes, read and multi-cast them to all clients.
Loop on Forever
Notice that no disk storage is needed for this server like it is for CGI. That's because messages are constantly being broadcast, so they do not need to be saved for the next time a user asks for an update-he's already got them all! It's this sort of "cool!" factor that attracts many people to Java.
One way around some of the tedium of writing your own chat server software is to use code that already exists. For instance, a Java program running in your browser can put an attractive and convenient front end on IRC. Many Java chat programs, in fact, do this, running as IRC clients in disguise and connecting to any IRC server in the world, as in Figure 40.5.
Figure 40.5 : Dimension X's Cafe is a Java-based front end to IRC, allowing chat on the Web.
Like Java, helper applications extend the capabilities of your browser, so that more flexible chatting is possible than with the simple transaction-based CGI method. But, unlike Java, helper applications are not downloaded and run on the fly, nor are they cross-platform portable. Users of helper applications must seek out, find, and install them on their own before they can be used. In this way, they are a lot like plug-ins, but without the tight integration with the browser that plug-ins can achieve.
Helper applications are the oldest form of browser extension and are being somewhat eclipsed by newer technologies. That said, however, many of the most elaborate chat systems on the Internet function as helper applications to Web browsers.
The implementation of a chat helper application is quite similar to that of a Java one, but the helper applications can be written in any language. It simply establishes a connection to a chat server and allows the user to type. In fact, chat helper applications only really use the Web to begin sessions. After being started by the browser, the helper application functions completely free of it.
Some of the more popular, and elaborate, chat helper applications include Virtual Places (http://www.gnn.com/gnn/vplaces), WorldsChat (http://www.worlds.net), and The Palace (http://www.thepalace.com).
When Telnet is used for Web-based chatting, it is similar to helper applications, with one slight difference: Where helper applications are tied to a MIME (Multipurpose Internet Mail Extension) type-so that when that type is received by the browser it executes the specified helper-Telnet is defined in the URL itself. Though almost completely an anachronism today, you may stumble across a link to a Telnet-based IRC or MUD session that could technically be counted as Web-based chat.
Telnet doesn't run in your browser, it's text-based and doesn't have any fancy graphical features, it doesn't allow icons or fonts or sounds, but it is very, very easy to set up. Sometimes the simplest way to add a quick-and-dirty chat space to your Web server is to just add telnet://irc.myserver.com.
Telnet clients ship with all versions of UNIX, Windows 95, and Windows NT. A free version of telnet exists for the Macintosh at ftp://ftp.ncsa.uiuc.edu/Mac/Telnet/Telnet2.6.
As of this writing, there are no ActiveX components or Netscape plug-ins specifically designed for Web chatting. Nothing, of course, prevents new software from being written using these tools, but despite the fact that each is capable of supporting chat, they have distinct disadvantages when compared to Java.
First, ActiveX is only supported on Microsoft platforms. If you are surfing from any browser that doesn't support ActiveX, a chat space built with this technology simply won't work. While there are similar concerns with Java, it is at least cross-platform, and Java-based browsers are available for all popular operating systems.
Plug-ins, unfortunately, require previous installation. While Java and ActiveX download themselves when they are needed, plug-ins must be downloaded separately and installed before they can be used. Additionally, plug-ins only run on browsers that support them, such as Netscape Navigator.
There is a basic minimum that a chat page on the Web must have to still fall into the category "chat." Beyond this, there are well-nigh an infinite number of bells and whistles that can be added to chat spaces to make them more attractive, or more usable, or more fun.
These additions are often found in pre-written Web chat programs, or the ambitious and knowledgeable can add them themselves. The limitations of chat on the Web are basically the limitations of the Web itself, which, as you know, aren't many. Let your imagination run wild and you can have the most unique chat page on the whole WWW.
Just a few possible features include the following:
Each, of course, has advantages and disadvantages, but by carefully choosing the capabilities of your chat server, you can end up with the perfect balance. Each of these features is detailed in the following sections.
You can allow your users to enter HTML with their comments, giving them the same flexibility you have when designing Web pages. This can dramatically improve the appearance of your chat space. Compare Figure 40.6 with Figure 40.7, for example.
The difference between these two chat sessions is that the second
is running on a server that allows HTML to be entered along with
the text. If a user types <H1>Yes!</H1> instead
of simply Yes!, the <H1> tag will be interpreted
as HTML when it arrives in the other chatters' browsers, causing
the response to appear much more dramatically. The same way, images
can be inserted into a chat session, simply by including the appropriate
HTML: <IMG SRC=http://www.myserver.com/user/pic.gif>,
for example.
| CAUTION |
The disadvantage of allowing HTML is that you give up control of a large part of your chat space to your users. For instance, what happens if a malevolent user starts including HTML designed to break your chat server? Simply entering <FORM><SELECT> makes any following comments invisible. Server-side includes are even more dangerous |
You must also consider the bandwidth your users have available
to them when allowing HTML on chat pages. While your visitors
may be content to download a few pages of text during a conversation,
modem users will probably be dissatisfied waiting for the large
picture that someone else entered the HTML for.
| CAUTION |
Bandwidth, in fact, is probably the major concern when considering the options you want to add to your Web chat pages. Users running at 14.4Kbps may very well give up if there is too much junk being sent. Pictures, Java applets, audio files, Shockwave animations, video feeds-any or all of these are allowed if you allow users to enter HTML. You should be sure that's really what you want |
One compromise solution that allows you to jazz up the visuals on your chat page, without drowning users in HTML, is to provide several predefined graphics for users to select from. On servers that use this technique, each message entered by a chatter is accompanied by an icon or small picture, as in Figure 40.8.
By using predefined images, you know that visitors with slower modems won't be deluged with graphics, but that your page will be interesting to look at. Additionally, these images can actually help the conversation. Text can often be very inexpressive, and what appears in a chat session can easily be misunderstood because it was not accompanied by a facial expression. By having icons that evoke different emotions, you can allow your users the freedom of expression they enjoy in real face-to-face chats.
Whispering is another nice feature that can be added to chat pages. Whispering is where a comment is directly sent to a single person, instead of everybody sharing the chat space. Having a Whisper option, as in Figure 40.9, as well as a more general Talk option can make your site more enjoyable.
If you are using a transaction-based CGI chat server, you might want to have it automatically include client-side pull information on each page it sends. On browsers that understand client-side pull, this causes an URL to be automatically updated after a time you specify-for example, in Listing 40.4, it's X seconds-allowing the user to see new information without having to interact with the page. Listing 40.4 shows the Netscape client pull HTML.
Listing 40.4 Setting Up a Page to Update Itself
<HTML>
<HEAD>
<META HTTP-EQUIV=REFRESH CONTENT="X;http://www.myserver.com/chat/url>
</HEAD>
...
Of course, client-side pull has disadvantages. It takes control of the page out of the user's hands and can easily time-out and request an update while the user is entering a comment. This can be very annoying.
Another possible feature is persistent aliases, where the user claims a chat name and is allowed to keep it for as long as he wants. Under the basic chat system, a user simply enters a name to use for each message he sends. The server has no idea if the Joanne who sent a message a minute ago is the same Joanne who has been chatting for the last half-hour.
But by installing a password system, where each user picks an alias and a password to go along with it, the server can make sure that this Joanne is who she claims to be.
Persistent aliases can prevent a lot of trouble-making. Often, annoying users log on as someone they don't like and start being obnoxious. Other chatters, fooled by the trickery, assume that the real user has suddenly become an offensive jerk, as in Figure 40.10.
Another possible addition to the basic chat scenario is the addition of multiple "rooms" to a Web server. This notion is more analogous to a real party than a simple Web chat, because as you move between rooms, you hear only the conversation taking place in the one you are currently in. By allowing users to jump between rooms, you can have several conversations happen at once, without them overlapping and getting confusing. For example, compare Figure 40.11 with Figure 40.12.
Also, by allowing multiple rooms, you can more easily handle large groups of people on your chat server. If a hundred people are gathered in one chat room, the conversation may progress too fast for anyone to follow, even if they are all discussing the same subject. By having multiple rooms-or even by imposing limits on the number of people in any one room-you can slow the conversation to a reasonable pace.
Because chat on the Web is usually open to the public at large, you might occasionally find an obnoxious or obscene chatter has planted himself on your sever. In the worst possible scenario, this individual will end up driving away the sort of people you want to have as regulars and attracting the sort you don't. More than a few chat servers have been overtaken by the electronic equivalent of unruly mobs and have ended up either being shut down or simply abandoned by their owners.
The way to avoid such trouble is to allow for certain trusted users to act as moderators, with the ability to cut off other chatters if they get too far out of line. While neither you nor your moderators will be able to monitor your chat server 24 hours a day, having the option to ban people who don't follow the rules can lead to a much more orderly environment.
Aternatively, if you are interested in maintaining some sort of civility on your chat page all the time, you can add message filters that scan user input for obscene or forbidden words. While there are foibles involved in using such filters-they can accidentally block allowable phrases and can be fooled into okaying prohibited ones-many sites have implemented them, including such giants as America Online.
Perhaps the ultimate visual enhancement to a Web-based chat space is the use of 3-D. By using either Java, ActiveX, plug-ins, or VRML, entire three-dimensional worlds can be added to the basic chat room structure. Instead of text spooling across the screen, word balloons appear over character's heads as they actually move around the room. This type of software blurs the distinction between chat and virtual reality and, for a while at least, bandwidth and computer-speed limitations put it well out of reach for all but the most wired Web users.
Finally, you might consider adding bots to your chat server. These programs, when run in conjunction with chat software, can provide help to users and Webmasters alike, offering assistance and taking care of menial chores.
What's a bot? Early Internet Relay Chat administrators used simple scripts to deliver preconstructed messages to users ("Thank you for visiting Zaphod's Galactic House of Chat"). Over time, these scripts evolved into programs that could make decisions on their own and carry on limited conversations with users. Today, they have matured even further, into self-sustaining automatic processes called bots (for robots).
A bot performs whatever function its creator intended. A helpful bot can engage in a little light conversation, respond to specific words typed into a chat session, and moderate topics. Some tend bar, some deal cards, and some enforce rules. There are also malevolent bots that try to annoy, confuse, or harass users. Many servers ban bots entirely, while others allow trusted users to bring their bots in with them. If this reminds you of the bar scene in Star Wars, it should-a lot of chat rooms seem to be based on that scene.
Rather than go to the trouble of fully implementing their own chat system, many Webmasters simply use the Web itself to find software that fits their purposes. Literally dozens of systems are available, and many of them are free and include source code, so they can be modified if necessary.
Unless you have very specific needs or are curious about how the process is accomplished, you probably don't need to write your own Web chat software. There is simply too much good, flexible code already in existence to bother: http://www.yahoo.com/Business_and_Economy/Companies/Computers/Software/ Communications_and_Networking/Chat lists several.
If you are interested in using CGI to set up a chat server on your Web site, a good place to start is with the basics. Hurray...!-Chat 1.0 is a free CGI-based chat server, written in Perl. While it doesn't have a lot of frills, it lets you set up a chat space in a matter of minutes and shows you the details of how to build your own, if you want. Hurray...!-Chat is available from http://www.rzuser.uni-heidelberg.de/~dhaese/sell.shtml, and is shown in Figure 40.13.
Figure 40.13 : Hurray...!-Chat 1.0 is a basic CGI-based chat server.
Of course, many commercial chat servers exist, too, often as enhanced versions of older free software. WebChat's latest version (http://www.irsociety.com) can be purchased, or its older, public-domain version downloaded (http://www.irsociety.com/webchat/webchat_gnu.html). Alamak (http://www.alamak.com) also has a revamped chat server for sale.
A good source for almost any Java applet is Gamelan, http://www.gamelan.com, and their collection of Web-based chat software is extensive. Browse to http://www.gamelan.com/pages/Gamelan.net.chat.html for a list, as shown in Figure 40.14.
Figure 40.14 : Gamelan is an index of many, many Java applets. It even marks the cool ones!
A nice example of how simple and straightforward a Java chat program can be is Annoying Chat from http://www.multivac.mit.edu/multimouse/annoyingchat.html. Despite the name, Annoying Chat is a solid implementation of a Java chat client that you can experiment with and learn from, or simply use as is (see Figure 40.15).
Figure 40.15 : Annoying Chat is a Java chat client.
While Annoying Chat certainly qualifies as a chat program, it only takes advantage of a small part of Java's capabilities. Since Java is a true programming language, it can take chat into an entirely new dimension, far beyond anything that's been done before. These "virtual worlds" aren't so much chat rooms as they are alternate realities.
For instance, Unearthed is a Java-based chat that is closer in appearance to a video game. You can choose characters, wander along paths, whisper, or shout. Though only an alpha version is available as of this writing, Unearthed (http://unearthed.mit.edu/unearthed) is a glimpse into the future, shown in Figure 40.16.
Figure 40.16 : Unearthed is a Java chat that looks more like a video game.
Helper applications for chat range from the traditional to the outlandish.
UgaliChat (http://netaccess.on.ca/ugali/chat) is a low-cost Web chat helper application in the classic mold (see Figure 40.17), however, much more elaborate services, such as WorldsChat (http://www.worlds.net) and The Palace (http://www.thepalace.com), push the boundaries. Avatars, 3-D, and virtual worlds are just a few of the things you find in the more complex software, but at a price. Only high-powered systems can run the client-side of the program, and the servers are very specialized and expensive.
Despite their differences, all these helper applications run the same way. A link on the Web connects to a server, which then responds with its own specific MIME type. If Netscape, for example, does not recognize a particular MIME type it receives, it prompts the user to specify a helper application to handle and then execute it. This helper then runs independently of the browser, using its own protocol to communicate. In many cases, helper applications can even be started on their own, without using a browser at all.
There is also an alternative to setting up your own chat server: It is possible to very easily create your own chat room on someone else's server. Many people have set aside the machine speed and disk space required to allow a huge number of people to maintain their own dedicated chat spaces on a single common Web server. This frees you from having to worry about such things as administration or upgrades, and allows you to have chat on your Web site without requiring access to the server's CGI-BIN directory or other esoterica.
Of course, by using someone else's server, you lose a certain amount of control, even if the room is your own. You cannot modify the chat program itself, or control how it looks to your users. You may not be able to get logs of who chatted and when, or transcripts of what was said. Also, some servers charge you a fee for the space.
The Annoying Chat home page (http://multivac.mit.edu/multimouse/annoyingchat.html), for example, tells you how to use the already-running server to set up your own chat room for free. Alamak (http://www.alamak.com) allows people to become remote operators for a small fee.
Using a third-party's server is an easy way to add a chat space to your Web site-your pages just need some setup HTML and you're done-but you should be aware of what you're giving up in the process.