http://chat.blackravendragoons.com/
There are still SEVERAL glaring bugs and problems with the software. Right now, most of these are issues related to how JavaScript handles scope (or most likely--my misunderstanding of scope). Also, most commands that I plan on implementing don't currently work nor are they implemented. And there's also a few potential issues that might crop up which I haven't yet dealt with. For instance, I don't really know what would happen if you were to try setting your nickname to one that already exists. In theory it may be possible, but it'll essentially orphan the previous nickname.
Also... the manner in which Internet Explorer handles unbuffered reads from a script isn't very pretty. The result is that it tends to lose messages that are sitting in the message queue and never bothered rendering them. I know there's a way to fix this, but since I don't have a lot of experience with writing JavaScript specifically for Internet Explorer, I don't know exactly what to do.
Nicknames are also NOT remembered between sessions. I'll work on that. Right now, you have to manually set you nickname.
Implementation details
(This is the boring cruft most of you won't really care about unless you're technically inclined, so don't read it.)
For the curious, here's how it works:
The back-end is written using Python and the Twisted Python framework. This interfaces with the client by utilizing very small PHP scripts that pass session information (that they generate) directly to the back end to maintain some notion of "state." HTTP doesn't support "push" type protocols, so all events have to be handled asynchronously. This means that whenever it looks like you're receiving a message from the server, you're not. Your client is actually connecting the server every second on the "get" script. While your client is idling, the server adds messages received for the channel (and for you) into a queue. This queue is sent when your client "wakes up" and asks the server for messages you've received. On the other hand, when sending a message, your browser sends the data directly to the server which then interprets it and dispatches it to the recipient(s).
So really, it's a very convoluted means of writing a chat server, but it's about the only way to do it well using AJAX. "Streaming" works (in the sense of never closing the HTTP connection)--if you're using Firefox and Opera. Internet Explorer refuses to work with this technique, because it won't actually parse or render anything until the connection is closed--so that little tidbit kinda sucks. Anyway, we'll see what happens. I don't imagine there'd be a huge load, because the back-end doesn't use a network connection to communicate with itself (it does use UNIX domain sockets, though).
Anyway, poke around with it. It might be interesting to see what we can do.
