Forum OpenACS Q&A: Jabber and Cronjob Modules Available

I have several modules that may be of interest to a few of you.

  • NSJabber module: This is a C module, with example tcl code in a tcl module. The The tcl module makes use of Rob Mayoff's threadpool module to handle requests and to protect the outgoing socket, but using this module is not required.
  • Cronjob module: This is an OpenACS4/ACS4 module. It works for both Oracle and PG. The module is has an admin only ui, since the cronjobs can be set to run arbitrary tcl code as well as sql queries. Each cronjob has an minute,hour,day,month,day-of-week field for scheduling. There are fields for approval of the cronjob, and for disabling the cronjob. There is also a party_id for use if someone adds a regular user ui. When a scheduled cronjob is run, the sql field is executed and formatted into an html table. Next any tcl code is run. Finally if there is a sql result table, and the email address field is filled in the table is emailed.

    Each cronjob is run in a separate thread. There is also a link to run the cronjob immediately.

Collapse
Posted by Don Baccus on
We need to get our repository up and running, don't we? :)

Should we include cronjob as part of our release?  We could probably get Simon to assign a tester ...

Also, where are these?  Do you have a place set up where we can download them?

And - hey, thanks!

Collapse
Posted by Tom Jackson on

Shoot, I always forget the most important part! The directory with the modules is http://zmbh.com/discussion/nsjabber/downloads/

I believe the cronjob module is ready for testing. The oracle version may have one bug (incorrect query), but the pg version is complete.

The nsjabber C module simply passes a reference to each xmlnode to a tcl procedure. The developer can define this procedure to do whatever is needed. The C module has additions and improvements over the libjabber C api. Mostly this allows a reference to the tcl interp to pass through the xml stream processor, and to realize when the client has been disconnected from the server. The tcl api includes the following commands:

ns_jabber test | new | delete | start | stop | poll | sendraw | send 
ns_jabber recv | stateget

ns_xode new | string | file | insert_tag | insert_tag_node |
ns_xode insert_node | insert_cdata | wrap | put_attrib | get_attrib
ns_xode to_string | get_tag | get_name | get_data | free
Collapse
Posted by David Kuczek on
Hello Tom,

do you have some documentation on your jabber module
somewhere?

What do we have to install on our server to make it running and
what does it do for us (in non-techie words maybe 😊

Thanks

Collapse
Posted by Tom Jackson on

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.

Collapse
Posted by Michael Feldstein on
Tom, what additional work would need to be done in order to
integrate Jabber with OpenACS as its IM/chat solution?
Collapse
Posted by Tom Jackson on

This module turns AOLserver into a client, which can communicate with a Jabber Server. Each client would take up at least two threads: one for the connection to the Jabber server and one for the display of incoming messages. I suppose the display could be an auto refresh type deal, but it still seems kind of expensive for large scale use. Intranets might be a different story.

What seems like it would be easy to do is:

  • Send messages instead of email, since jabber stores your messages when you are offline.
  • Record groupchat. I have already set this up without OpenACS.
  • Maintain a whose online database.
  • Record a weblog -done.
  • Provide a way to send messages to an OpenACS discussion bboard.
  • Provide a "box" where web users could send a message to a jabber groupchat, chat or jabber user, probably by maintaining the user@server/resource and password, and a list of buddies you want to know about.
  • Provide a way of creating a jabber groupchat room -done.

I guess it really is up to what we need and can live with for IM in OpenACS. Anyone have an opinion?

Collapse
Posted by David Kuczek on
I would really like to see your Jabber module as the Chat/IM implementation for OpenACS.

Maybe you could explain the pros/cons of your module versus the Java Jabber-client...

( http://jabberapplet.sourceforge.net/ )

To make your solution run you would have to:
1. Install the Jabber-Server
2. Install your module
3. Write a display (tcl maybe)

Do you plan on writing a display?

You were talking about scalability:

"I suppose the display could be an auto refresh type deal, but it still seems kind of expensive for large scale use"

Exactly how scalable do thing your module with the auto refresh would be?

What could be done to make it more scalable?

Thanks

Collapse
Posted by Michael Feldstein on
My first priority would be to make some kind of minimal chat
room available for people who need it. As I see it, that means we
need a couple of things:

- The ability to spawn a chat room (done?)

- The ability to log a chat room conversation (done?)

- The ability to tie the chat room to permissions (not done?)

- Some kind of chat room client

On this last point, I personally am OK about letting people
download whatever jabber client they like and maybe including
one of the Java clients with OpenACS. However, I understand
that some folks prefer not to require client-side Java since
Windows is now shipping without it installed. In that case, we
would need some kind of in-page javascripty thing with
auto-refresh. (Ugh.)

One other thing that sounds like it might be easy and worthwhile
to do is to create a service contract for a presence indicator that
could be called by other modules.

In terms of other applications for Jabber messaging, while I'm
open to the idea, I have yet to hear of an application that strikes
me as very useful. The only thing I could potentially see is to use
as a bridge to a text pager or some other wireless device. Other
than that...

Anyway, thanks for the good work, Tom.

Collapse
Posted by Tom Jackson on
Maybe you could explain the pros/cons of your module versus the Java Jabber-client...

The module makes AOLserver into a Jabber Client. the Java JabberClient, doesn't.

To make your solution run you would have to: 1. Install the Jabber-Server 2. Install your module 3. Write a display (tcl maybe)

You only need an account on a Jabber Server, but I would recommend installing a local server. This module is a client, trying to get AOLserver to be an efficient server would be not easy.

Exactly how scalable do thing your module with the auto refresh would be?

You would still have one connection thread per user. A minimum or 2 Meg of ram per thread. If you don't mind buying the ram, that is the only issue that I see. Maybe you could keep the client state in the connection thread, but then how would you get it to the display thread? Obviously some sort of nsv array would be nice, but you would have to key it so that you could flush the array when a client disconnects. Also you would need some way of determining when a client was really in need of being closed.

If you didn't mind about maintaining presence, you could set up a system where the jabber client would periodically connect to your jabber server accounts and drain the messages. Some way of per user processing of messages would be really nice, or when a client connects via the web, they could hand process messages.

I had also proposed in another thread a personal installation of OpenACS: the jabber client is then all yours and the sky is the limit. It would be by far the best local client you could get, IMHO. I don't know if the libjabber and libxode libraries compile on WIN platforms, probably not.

Collapse
Posted by Malte Sussdorff on
Okay, now I jump in here, as my students are, well, afraid, busy,lazy to answer. They have written a Jabber Client with an additional Jabber Server Module wich allows the remote administration of the Jabber server, e.g. to add other users to the Rooster of the Jabber Server. Very useful if you use another Client like the Java Applet and want to see who of your working group, team or whatever is online, as this information can be updated automatically form the ACS System. I wanted to wait til the source is tested and better documented, but well, before someone else develops the same functionality. In general this setup is a little bit centered around the Jabber Java Applett for communication. Logging will be handled by the Jabber server.

jb_login

  - This function takes no parameters, it logs the community client into the
Jabber Server. A call to this function should be done on AOLSerevr startup,
or after a restart of the Jabber Server a automatic login on startup is in
work but not implemented yet.
The clients jid as well as the Jabber Server URL have to be defined at
compiletime.

jb_logout

  -This function takes no parameters, it logs the community client out of
the Jabber        Server.

jb_addbuddy  screenname screenname screenname ...

  - This function is not limited to the amount of parameters,each parameter
must be a valid sreenname (a screenname is a jid with out the Server portion).  The first parameter has to be the screenname of the user who wants to add
someones jid  to his roster (e.g. the one who is triggering this function),
all other parameters are  the screennames to be added to the firsts roster.

If a screenname contains invalid charakters this function returns an error,
if a
screenname is spelled corectly  but is not valid the function will not
return an error      and no action to this specific screenname takes place,
but it will still apear in all      valid screennames rosters.

jb_chat screenname screenname

  - This function takes two parameters, both are screennames  (a screenname
is a jid with  out the Server portion) , it will start a chat between the
specified users.Even if both are offline they recive at least a "Hello" and
all masseges send, when they go online  the next time.If the screenname or
the password contains invalid charakters this function returns an error.

jb_register screenname password

  - This function takes two parameters, the first is the srcreenname of the
user to be          registered the second is the password.If a screenname
contains invalid charakters this      function returns an error.

jb_message jid message

  - This funktion takes two parameters, the first is a full jid (of any valid
Jabber Server
    including its transports) , the second is the message String.This
function dosen't        return any errors yet.


Ther is also a table in the Database of the AOLServer that holds all Users
who are online  with the Jabber Server from any client.The table has three
columes  jid and resource wich  make the primery key of the table (this is
because a user can be online with two or more    clients at the same time
from diferent recources ( Home , Work , etc.) ), and the third  colume holds
the current status ( online , away ).Details about the table will follow.

Collapse
Posted by Malte Sussdorff on
Michael, getting alerts not via EMail but via Chat and having the option to browse members of a community who might have answers to a question and clicking on a link to start a conversation would be too useful things jumping into my mind. But talking about the applications of a Jabber solution is a completly different matter.
Collapse
Posted by Bjoern Kiesbye on

Hi,
the modules described in the post above can be found at www.sussdorff-roy.com together with a detailed instalation documentation, and a tcl doc.

Collapse
Posted by David Kuczek on
Bjoern,

looks great. I will try to get it running on our servers some time
soon...

BTW, your formating on the site you just mentioned is really
messed up... It might be, because I am accessing it via an iMac,
but you should check on it anyways.