Forum OpenACS Q&A: Response to Jabber and Cronjob Modules Available

Collapse
5: Response to Jabber and Cronjob Modules Available (response to 1)
Posted by Tom Jackson on 10/19/01 07:57 PM

All the software you (may) need to install can be found at http://zmbh.com/discussion/nsjabber/, mostly in the download directory.

First off you have to install the libxode and libjabber libraries. The original libraries install fine on RH7.0+, but not on my RH6+ systems. The tar file on my site includes a version of these libs that installs on a RH6+ system. The problem has to do with libtool. Once you have installed those libs, you should be able to compile the C module. You need to edit the compile script to reflect the location of your ns.h, and jabber header files.

There are actually two C modules. One stuffs chat packets into a chat db table, and groupchat packets into a groupchat db table. I abandoned this in favor of the second module, which simply passes a reference to the packet xmlnode to a tcl procedure. So essentially now, each packet can be processed completely in tcl.

The module also provides the tcl api necessary for extracting information from the packet xmlnode, creating new xmlnodes, and sending them.

To utilize the package more efficiently, you should install Rob Mayoff's threadpool module. The tcl module that is provided makes use of this great module by taking the incoming xmlnode and processing it in a separate thread (not the receiving thread). When the tcl application sends an xmlnode, it uses another threadpool that has only one thread, essentially creating a queue around the sending thread. This module is available from http://dqd.com/~mayoff/aolserver/.

The provided tcl module has a very useful procedure that connects to an account on any Jabber server. The useful part is that it detects when the connection goes down and reconnects. This works even if the connection thread dies, since it is a schedule procedure. Also included is sample code, demonstrating most of the tcl api.

I also hacked a simple way to provide a 'browsable' application. I stumbled across Jabber in August because of an article in _Linux Magazine_. The author had almost perfected a survey module. However, is was an amazingly painful process, certainly not easy in perl, even by a expert programmer. More info on that client can be found at http://www.saint-andre.com/jabber/surveyor. I have three example applications set up: time, echo and login (setup an account on OpenACS4).

So in my humble opinion, the AOLserver Jabber module provides an un-challenged platform for writing Jabber Clients in the simplest possible way.

However to my dismay the Jabber Protocol suffers from a few very nasty problems:

  • The Jabber Protocol doesn't handle arbitrary data transfers, only xml, and xml safe encodings.
  • Arbitrary and very low message length limits, something like 10K.
  • Everything is in xml. EVERYTHING. The client must understand xml, the server must be able to parse every message that passes through. Apparently the server only understands a subset of xml, so clients are limited by the server.
  • There is mass confusion by new developers on what states the protocol supports. Presence is a good example. The presence tag has a type attribute. The types include available, unavailable, subscribe, subscribed, unsubscribe, unsubscribed, and probe. A sub tag of presence is show. The show tag lists the 'exact' user availability, and can be one of: away, chat, xa (extended away) or dnd (do not disturb). So the confusion is that the show tag doesn't do anything. Availability is either: 'available' or 'unavailable'. If you set 'available' and have a show tag containing 'away', you are still available. Make sense? I still don't understand why the type attribute can be either a state, or an action to be performed.
  • The above limitations have lead to the x namespace, which can contain anything compatible with xml (and does), and the x:oob sub-namespace which tries to handle the problem of transfering data outside of the jabber protocol.
  • Transports. Jabber attempts to piggyback on other availble messaging protocols. The most disasterous example is the AIM network. AOL is able to block any large server that provides a transport to the AIM network. They are also able to detect messages sent by an AIM transport that wasn't compiled with the correct version of files. You can send a message or two, and then the AOL servers disconnect you.
  • Security. Security is slightly better than AIM, mostly because you don't pass through one big main server. Otherwise, there is no 'Secure Jabber Protocol'.
  • TCP Only. All chat and groupchat and presence is via TCP. I would think that presence and groupchat would be better handled via UDP. Unfortuantely Jabber is an xml stream, requiring a continuous connection.
  • No Peer-To-Peer.

Anyway, that's about it for now.