This is something I wrote today in alt.fan.dragons OOC. It has
some insight on
- How web chats and chat systems in general work,
- 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. =) ]