Forum OpenACS Q&A: Chat and Push Technology

Posted by David Kuczek on
I actually have two questions:

1.) Push Technology

Within the 3.2.x chat module you can invite people to the chat via
email only, which is not very efficient I believe.

It would be nice, if the chat would also have the following

- A member selects another member out of some kind of interface
like "/directory". He can either send an email invitation OR a push
invitation to the selected member. The option to send a push
invitiation is only activated when the selected member is *online*.
The push invitation appears in a pop up window on the selected
member's screen right after it was beeing sent.

- A member sends an email invitation to a member that is *not* a
member of the community yet or would be too time consuming to look up
in the directory interface.

2.) Advanced Open Source Chat

Is there an advanced Open Source Chat Module (maybe a Java applet)
that OpenACS could integrate within its infrastructure that *doesn't*
force people to download and install a client like Jabber? Or does
Jabber offer this functionality as well?

Muchos Gracias

Posted by Kenny Chan on
Dave, Check out the java applet client for Jabber and Jabber server itself. The applet and the server works pretty good, I just wonder how we could integrate it with OpenACS. In fact, I have been thinking about this for some time, any suggestions please? Or anyone with more experiences with Jabber? Thanks,
Posted by Ryan Campbell on
If the Jabber server were integrated with OpenACS, you could just let people use their regular IM account (provided when they register) and Jabber would be responsible for telling OpenACS who's online. That way you could get cute little icons next to someone's name when they're online.

And then for people who haven't been introduced to the wonder of IM, you could have a link to the Java Jabber pop-up window. However, I'd probably just tell them to go get an AIM account instead of dealing with signing java applets. You can always use AOL's java client if you aren't at your own terminal.

Posted by Tom Jackson on

I've just started to look at Jabber, but it looks like all you need is to create a client, not a server for aolserver. I haven't been able to find a C api for the server, so if that doesn't exist, integration will not be easy.

I'm also wondering how you can efficiently handle the xml streams. It seems like you have to process char by char.

To complete integration with Jabber, you can just run the open source server and send and receive messages with the client.

Posted by David Cohen on
You might want to keep tabs on this thread about Jabber and the ACS on the web/db forum at

It starts with this (and goes from there):

I'm investigating integrating ACS with Jabber (see instead of a
    straight port of our Chat Package. Does anyone have perspectives or
    experience on this? 

-- Tracy Adams, August 1, 2001

Posted by Tom Jackson on

But, that will be Java, and we can't look at ACS anyway.

Has anyone heard of LT XML? A reference is

It supports input/output streams, and has an API. I don't know if it is open source or not. LibXML doesn't look like it supports streams.

Posted by Talli Somekh on
I think we do need to solve the Chat problem for OpenACS, and indications are, at least for now, that Jabber will solve those problems better than anything else. Tom, I have never heard of the project you linked to, but that could be cool.

We looked at Jabber integration very superficially. Basically just looked at the docs. But from what I remember, the back of the envelope thought was that since Jabber keeps its user info in an XML file, you could sync it with the OpenACS permissions (who's logged in, etc.) stuff reasonably easily. So Jabber integration with OpenACS seemed to be rather straightforward, if you're just trying to do chat.

Of course, the really cool thing is to try to use Jabber as a Messaging System (capitals indicating an institutional importance). In other words, leveraging its XML data exchange for use in alerts, rosters, email, etc.

I recently started subscribing to the Jabber mailing lists mostly to get an idea of what the community is like. It's very active and the people seem to be very smart and motivated. It's very beuracratic as they have JIGs (Jabber Implementation Groups) and some other things, but in some ways that's good because it forces people to be serious about their conributions.

I think that if someone were to take this project on full force, he or she could find a lot of support here and in the Jabber community. Currently, Jabber really doesn't have any asynchronous communication nor does it appear to have DB support.

I could be talking out of my well padded you know what, but that's m .02.


Posted by Don Baccus on
Matthew Burke did some work on this while at aD and he and our ever-industrious Neophytos Demitriou have been talking about it behind
our backs.

Naw, no secrets, Neophytos just pinged Matt to see if any code was available from his efforts and whether or not he'd be interested in working on it again ("mostly no", and "yeah some but I'm busy with a brand new job" being about as far as the conversation has gotten).

Posted by Malte Fliedner on
Hi everybody,

We are actually working on an integration of the Jabber Server into the ACES right now, so I would like to introduce our approach and tell  you of our plans and the problems we are facing.
We decided to let the Jabber Server run separately and not directly implement the Jabber functionality in the Aol Web Server. Although the latter would make direct administration possible, we were not quite sure which additional problems and difficulties this would bring about and thought it was better to have the possibility to run the two servers on different machines.
So we want to “turn” the ACES into a client of the Jabber Server, which has all the users of the ACES as buddies in his roster.
This should just give you a brief description on how things are supposed to work:
When a User registers in the ACES for the first time he is asked for a Jabber screen-name (jid) and password which is stored in the ACES database and is then automatically registered with the jabber server. This is done by the ACES which simply logs in the Jabber Server with the new members jid and password. Registration (note: not authentication) can only be done by the ACES (we have to write a short mod for the jabber server which bounces all other reg requests from other clients). After this, an Applet (we are using a client from at the moment) starts, which authenticates the user with the Jabber Server. This applet will handle the user communication for us (just like Aim Express) and will be started whenever a user of the ACES (someone who already has been registered) logs in.
Now, the ACES itself is always logged in the Jabber Server as a client and whenever a new User registers with the Server he is automatically added to the buddy list of the ACES. This makes it possible to track whether an ACES member is online with Jabber or not, as the presence information of all buddies is pushed to the ACES by the Jabber Server and can then be stored in the database for further processing. It also makes automated communication between the ACES and its Users possible, e.g. for announcements to all or groups of users or alerts. It is necessary that all Members have the ACES as buddy in there buddy list to receive the above described notifications (messages), we are working on making this buddy predefined and static (not removable).
We will probably use the group module (of Jabber) which has the capabilities that are necessary, but in fact it didn’t do what it was supposed to yet. It might just be a configuration problem, if not we will implement this functionality with a self written C module .

We already have implemented the Jabber XmlParser and libraries for the connection in the AOL Server. Furthermore we are using a library from EVERYBUDDY, which is a multi-protocol  C chat client, to add the client functionality.
The major problem we are facing is that Jabber does not provide an interface for remote admin. In the “Jabber World” only the clients themselves are supposed to be able to change their rosters. So if you want to be able to change users rosters by the ACES, this makes further effort necessary. One possible way would be to simply let the ACES log in the Jabber with the jid and password of the corresponding member, just like we do when we register clients for the first time. But the problem is, that the client could already be online with Jabber, which can lead to conflicts. Jabber provides the possibility to log in with different resources on the same account at the same time. So you should be able to login with another unique resource, do your roster changes and then log out again without disturbing the client.
On the other hand you could extend the Jabber Server functionality by own admin tags, which trigger the Server functions for roster changes etc.
We think both approaches have advantages and disadvantages, so we are still figuring out how, if at all, we want to proceed with this.
We have already managed to let the ACES log in the Jabber Server and should also be able to retrieve the presence information. But we had some trouble with the AOL Web Server (nothing to do with Jabber, probably) today, so we were not able to test it.
As we are, at the time, working on this project everyday we would appreciate any comments, notes, hints, questions or criticisms related to this topic.

                                Bjoern Kiesbye,
                                Malte Fliedner                                            Students of the University of Hamburg

Posted by Tom Jackson on

I found a better link for LT XML: It is released under a GPL license, and now has a Python interface.

From that page:

LT XML is an integrated set of XML tools and a developers' tool-kit, including a C-based API. The release now available will run on UNIX and WIN32.

The LT XML tool-kit includes stand-alone tools for a wide range of processing of well-formed XML documents, including searching and extracting, down-translation (e.g. report generation, formatting), tokenising and sorting.

Sequences of tool applications can be pipelined together to achieve complex results.

For special purposes beyond what the pre-constructed tools can achieve, extending their functionality and/or creating new tools is easy using the LT XML API. Minimal applications require less than one-half page of C code to express.

LT XML provides two views of an XML file; one as a flat stream of markup elements and text; a second as a sequence of tree-structured XML elements. The two views can be mixed, allowing great flexibility in the manipulation of XML documents. It also includes a powerful, yet simple, querying language, which allows the user to quickly and easily select those parts of an XML document which are of interest.

Also just publicly released is the next version of an interface to Python, allowing the quick development of graphical user interfaces using the LT XML API.

Everybuddy seems to require a lot of extra libraries to be compiled in. Does anyone know any more about this one?