Forum OpenACS Q&A: Chat and Push Technology
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?
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.
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.
It starts with this (and goes from there):
I'm investigating integrating ACS with Jabber (see jabber.org) instead of a straight port of our Chat Package. Does anyone have perspectives or experience on this?
-- Tracy Adams, August 1, 2001
But, that will be Java, and we can't look at ACS anyway.
Has anyone heard of LT XML? A reference is http://www.ltg.ed.ac.uk/corpora/xmldoc/beta/p209.htm
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.
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.
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).
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 sourceforge.net 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.
Malte Fliedner Students of the University of Hamburg
I found a better link for LT XML: http://www.ltg.ed.ac.uk/software/xml/index.html. 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?