Improving Tcl Chat

This page was created to discuss how to improve the Tcl'ers Chat - JCW

So what's wrong? Well...

it's a CGI doing periodic refresh, that eats bandwidth and CPU resources and both are starting to become an issue
it is used by Bruce Hartweg's TkChat, which then has to go through the trouble of decoding stuff which was not really designed to be easy to parse and process further

There are lots of ways to take this further. Recent experiments with Cgi-irc (a web-based gateway to IRC) and with some experimental code I wrote at http://mini.net/t/ show that there are a number of issues before we have a satisfactory replacement:

first of all, the big advantage of the current system seems to be that it works through everyone's firewall
second, Ralf's Chat (see http://www.ralfchat.com/ ), as the perl script is called, does have quite a bit of features: login management, user lists, private msgs, and sending messages to someone who is not currently around

My goal for now is to quickly find a few simple and robust solutions to stay out of trouble with CPU load and bandwidth. The CPU load seems to already be making the Tcl'ers Wiki itself sluggish, especially with updates. And the bandwidth... well, I'm starting to reach the limit for this server, and more than 50% of it is the chat. If it grows much further, it'll cost (a small amount of) real bucks.

Here are some ideas for improving this:

adjust the perl script to save a copy of the current history on file, in a format which can be easily read by TkChat, then adjust TkChat to read that page directly off the server, instead of via CGI
save perhaps a second copy of the history as HTML with the header containing a "Refresh" item so it will self-refresh every 15s. Then adjust the perl script to point browsers to it. The idea is that with frames, the history frame can simply point to this page and self-refresh without any CGI in between. The impact is that the refresh period becomes fixed as 15s for everyone.

A bit further down the line, I'd like to also revisit the idea of having a CGI script which "pushes" a signal that the history has changed. It could be used by TkChat to listen to, instead of doing a periodic page poll/pull. This will need to be optional, since push will not work through all firewalls (proxying ones will probably not allow the push connection to be kept open).

Comments are welcome... what this all is meant to say is that we need to do something about the chat before it becomes a real problem on mini.net.

April 2002 - FWIW, the bandwidth and cpu load issues are no longer a concern (heftier machine, and much higher limit) -jcw

Why we use this CGI based chat and a possible replacement

PT 21-Mar-2004: At various times during the lifetime of the Tclers chat people have questioned the reason for it's existence. After all, there is IRC. The main reason for continuing to use Ralf's chat is that HTTP provides the lowest common denomintator access. A number of people involved in the chat live behind restrictive firewalls. Mine is about as restrictive as they come -- all internet access is via a web proxy. It refuses to honour KeepAlive requests on port 80 and will only do SSL connections to port 443. This has to date precluded the use of any Web-IRC client I have tested.

The current chat setup is a lot less bandwidth intensive than it used to be and also a lot more responsive (if you use tkchat). This is due to jcw's chatter.cgi script. However, there are better systems and if you are used to using IRC and/or one of the instant messaging (IM) networks this is yet another window taking up space. The IRC bridge goes a long way to help with this.

However, it turns out that Jabber can successfully be used from within the restrictive setup described above. Jabber is an instant messaging system that provides messaging, chat rooms or conferences and also has gateways to the other IM networks. It also includes a specification for a HTTP polling access method (JEP0025) as a final resort. This means that you should be able to use any jabber client to access the chat. As a final resort we have found and setup a web-jabber site that also works from inside a restricted-proxying network.

I propose that we shift to jabber as a chat and IM platform.

We currently have a Tcl friendly jabber server available that is running a conference with a bridge to the #tcl channel on irc.freenode.net at [email protected]. This server also operates a web interface into jabber at http://sr-tech.com/ . However, suitable clients are Gaim [L1 ] and Tkabber.

Using Tkabber, we can access the jabber network from within our restrictive environment by registering a jabber account with jabber80.com. This server operates on ports 80 and 443. If we use a tkabber starkit that includes the tls extension then we can point our client to jabber80.com port 443 and we're away. Join the [email protected] chatroot, bridge to yahoo or msn or just jabber to your associates.

kroc has made some modifications to tkabber to improve its use on this conference and its look under X. Get starkit

https://www.tcl-lang.org/starkits/tkabber.kit

You can obtain a list of public jabber servers at [L2 ] or try it out with a test account [email protected]

 login: tcler
 password: tkabber
 server: jabber.org

As tkabber is written in Tcl, I see no reason why anything that we deem to be mising from this client cannot be added in the same way we currently hack on tkchat. An advantage is this should help to improve tkabber over time too.

You can join #tcl irc channel by joining jabber conference tcl%[email protected]

[ Category Tcler's Wiki | Category Internet ]