(idea) by WWWWolf Thu Apr 19 2001 at 13:32:18

This is something I wrote today in alt.fan.dragons OOC. It has some insight on

  1. How web chats and chat systems in general work,
  2. Why you should consider IRC instead of web-based chats if you're making them.

Summary: Dedicated protocols (IRC) are better than protocols not designed for the purpose (HTTP) or re-inventing the wheel (Java chats).

(No, I don't usually use the Java Chatterbox either. =)

Fengren <Fengren@techfreak.to> writes:

could someone help me out and point me to the basics of designing a chatroom? I'm not entirely sure I understand the specifics of how to do the interactions. (I'd like to do it in html, mostly because I don't have alot of experience with Java) Pwese? someone?

(First of all, HTML is not a programming language, it's a markup language. You need to use a real programming language, like Perl or Java.)

Here are some suggestions:

Use IRC. Form a new channel in some well-known network and set up a bot to keep the channel up. Don't bother with web chatrooms.

The problem with web-based chats is that no one is going to come to some random web page to chat... publicity is the problem. In IRC, the channels are always in channel lists. You can simply create a web page to publicize the channel and instructions on how to get there.

Furthermore, WWW is ill suited for this sort of tasks. It's a hypertext network, not a Great Wonderland of Real-Time Communications. You either need several abuses of HTTP protocol or some client-side stuff like Java, and neither is exactly a dream to implement or use.

It's possible to use normal HTTP and HTML to create a chat, though it's just that the browsers aren't exactly enthusiastic to support this sort of things.

Here's a simple chat simulation (not made by me):

http://db.cs.helsinki.fi/~rista/cgi-bin/um/chat.pl

This is a junk generator. It's not a real chat. None of the people there are real. Nevertheless, it mimicks real web chat systems fairly accurately what comes to the content. =)

It works like this: The server sends

Connection: close
Content-Type: multipart/x-mixed-replace;boundary=---ThisRandomString---

---ThisRandomString---
Content-Type: text/html
<html><head><title>The page title</title></head>
<body>
...chat lines come here...<br>
...for all eternity, until browser is closed...<br>

It'd possible to, say, use that sort of streamed HTML in the chat display frame, and have a form for chat line submission in other frame or browser window.

The CGI script that replies to chat form then talks with the program that runs the chat server, and the CGI script that spews out the chat lines reads new lines from the chat server.

This will require severe abuses of web design and perharps scripting - not to even mention the common sense and normal laws of sanity - to work. For example, what happens when user pushes Submit (will it stop loading the chat frame?) Will the user know what to do if the chat frame stops loading?

The architecture in crude ASCII looks like the following thing. It also illustrates the basic principles behind how the chat systems work. (UML or SA diagrams may be available on request, depending on if anyone needs that sort of things...) 

             Chat Server    (Continually running process that receives
                | ^         stuff from all ChatSubmissions and sends out
                | |         stuff to all ChatSpews)
                / \
               /   \            (One Spew and Submission per user)
              v     \
         ChatSpew ChatSubmission      (CGI scripts that handle reading
            /          ^              and writing)
           /            \
          v              |
      CGI Request     CGI Request     (Web server's idea of connections)
      (continual)     (single)
          |               ^

          |               |
          v               |
       ( . . . The Internet . . . )
          |               ^
          |               |
          v               |
       (. . . User's web browser . . .)
          |               ^
          v               |
      Text frame      Chat Form       (What the user sees)

Then, the other choice: Set up a chat server and use Java Applets as the interface.

This is technically better choice because you can use whatever you want as the protocol. No need to wrestle with protocols and markup languages that were not designed for real-time chatting.

The client side is the problem. Typically the chat clients are more limited than IRC clients, and eat A LOT of memory and processing power compared to IRC clients. Most common thing I've heard from Java chat users was "I wish I could do something else while I'm chatting!"

Technically, I'd choose the system that has been designed for chatting all along... IRC.

(Yes, I'm studying in the place where IRC was invented. No, I'm not biased. =)

[About the Author: WWWWolf is author of WolfConcert, a never-completed Java-based chat server that is also supposed to run as a stand-alone system. Then he got bored with Java's socket API and got back to IRC. =) ]

I like it!

Log in or register to write something here or to contact authors.