Friday, 30 July 2004
Recently, I received my Masters in Computer Science, having Distributed Systems as my main subject. Now, I work at the same university, in the Mechanical Engineering department as Scientific Programmer. Since the second half of 2000, I have been involved with Jabber, almost immediately being very interested in the protocol, its (possible) uses and future direction. Ever since, my personal website has been a playground for using Jabber in creative ways and prototyping various Jabber based protocols.
What I did so far
Most of my Jabber protocol related work is concentrated on presence and publish-subscribe related protocols. My contributions to the JSF's protocol work has been prototyping/implementing some of these protocols and being very vocal on the standards-jig mailinglist, occasional protocol discussions in the foundation conference room, and direct correspondence with the authors of such protocols. Also, I've contributed to the IETF XMPP WG discussions.
Following, a list of JEPs I've been involved with:
JEP-0060: Publish-Subscribe. Strong contributer, implementor.
JEP-0080: User Geolocation. Contributer.
JEP-0107: User Mood. Co-author, implementor.
JEP-0108: User Activity. Primary author.
JEP-0118: User Tune. Implementor.
I have been involved with pubsub ever since the first pubsub JEP by DJ Adams and used moods as a test case, even before the User Mood JEP had been written, first using DJ's protocol, later using JEP-0060. Also, I've been using both pubsub protocols for publishing news items to Mimír (see also Mimír's architecture), while implementing Idavoll, a generic pubsub service implementation.
A number of important JEPs covering pubsub, disco and file transfer have recently advanced to either draft or final status. This is a nice accomplishment. Now, we need to ensure that there are implementations of these protocols, so we can have hands-on data on the protocol's usability and potential problems. This makes it possible to enhance the protocols to be a good bases for writing Jabber based applications, without developers having to reinvent the wheel.
Also, a major focus point this term should be the protocol suites (Basic, Advanced, and Extended Presence). Instead of having implementors specify a potentially very long list of supported JEPs, these protocol suites describe nicely grouped sets of JEPs to be implemented for certain use cases. For now, these are mostly aimed at using Jabber for IM, but we might also need to look for other use cases.
On the other hand, the Council should continue to prevent filling the JEP list with niche protocols. Instead, the focus should be on providing the building blocks for building useful applications, in a generic way. Quality over Quantity.
Finally, I think the Council should regularly have meetings again, and also provide for regular protocol discussions. In my experience, when focussed on well-defined subjects, the protocol discussions have proved very useful and inspiring.
I am an active contributor to the JSFs protocol work. Besides commenting on protocol proposals, I also tend to try them out, often asking many questions. Writing code against a specification is the best way to find issues with them, when done with care. On the other hand, I believe that clear, unambiguous, and complete specifications yield better implementations. I think I can be instrumental in bringing those two together.
While XMPP is the basis, the JSF, with the Council at the helm, defines the higher level building blocks for the next generation of distributed systems. I believe I can help the JSF crank out the best protocols we can, through offering my expertises as a member of the Jabber Council.
Thursday, 22 July 2004
Intosi didn't get his Python script to talk to Rhythmbox, where it did for me. He was intending to make a little User Tune client himself with it. I was able to connect to Rhythmbox and ask for its properties, like song information and whether is was playing or not. However, that was polling, and since pubsub is hot and polling is not, I wanted to be notified by Rhythmbox when its status changed. Well, fortunately Rhythmbox also has an Bonobo event source to which you can assign handlers, and the Rhythmbox source had a test program in C to use this facility.
The C function for this is called bonobo_event_source_client_add_listener(), and appeared to have a Python binding, too. I didn't get it to work, though. It complained about having too many keyword arguments. It turned out that the binding code was incorrect, and the nice guys from the #pygtk IRC room promptly fixed the code in CVS.
Following stpeter's mantra #2, I went ahead and implemented Tune. Tune is a little tool that watches Rhythmbox and publishes information about the currently playing song to a pubsub node, using the User Tune protocol as defined in JEP-0118.
The first part was easy. If you have a running Rhythmbox and then start Tune, it nicely watches Rhythmbox and publishes away. The problem comes when there is no Rhythmbox when starting Tune, or when Rhythmbox is exited and possibly started again. I wanted to be able to detect when Rhythmbox was running or not and the #pygtk folks told be how to use the Bonobo Activation Framework to do that. While you can watch register and unregister events, those events don't give information about what got registered, so you have to find out yourself. This is a point of improvement, I'd say.
Tune is a nice proof of concept, and I also set up a Tune monitor for ralphm.net to show the Tune information in the Jabber Fish Tank and on the Jabber World Map. For the future, I'd like to see such publishers integrated into Jabber clients. Maybe a Jabber desktop daemon, to which local applets can talk, would be nice for this as well.
If you want to try out Tune, and have your tune information shown
ralphm.net, let me know.
Thursday, 15 July 2004
Every now and then, I receive requests from people to be added to the Jabber World Map. Some of them by e-mail, which is odd in itself, but mostly via Jabber. I'm in the habit of leaving the chat windows with those requests open on my desktop, until I've made the time to honour the requests. But lately, I've been testing out newer versions of Gabber and Gossip. Sometimes, as with most work in progress, they crash and I also loose the requests. Sure, I can look them up in the log files, but sometimes the request don't even get there in the first place.
So, if you have requested to be added to the map, and you haven't got any response or you still don't show up on the map, please try again. Just send another request, and I'll try to add you before the next crash. Note: I generally deny subscription requests for my personal presence, mostly because of the Dunbar Number (as Joe puts it).
To the client authors: you are doing doing a terrific job. keep up the good work!
Sunday, 11 July 2004
Lately I've been hacking on Idavoll's rewrite in Twisted. I'm now at the point that I can claim the most basic protocol requirements as defined in JEP-0060 have been implemented in Idavoll, a Jabber based Publish-Subscribe service.
I managed to find a nice architecture for Idavoll that makes it
possible to write different storage backends, and use Twisted services to
implement the various parts of the pubsub protocol. Currently, there is
one service that implements the mandatory pubsub stuff, and one service
that does the Idavoll specific stuff, like responding to
jabber:iq:version and Service Discovery
I make a distinction between Idavoll and the pubsub service
implementation. Idavoll is a complete server side component, of which the
pubsub service is one part. In the future, Idavoll might also interact
with other protocols such as HTTP or XMLRPC. These would be separate
services communicating with the backend. Also, we could listen for other
Jabber based subprotocols like presence, and implement those as seperate
services too, interacting with the rest of the component. The Idavoll
specific service asks the other services for replies to a disco request
and collects the answers to form one reply. Maybe this should become part
twisted.protocols.jabber.component down the road.
I'm still playing to find the best way to implement this, though.
The only backend available at the moment is a memory based one. It
stores all data in python structures instead of relying on files or a
database. Currently it is pretty static, as Idavoll does not jet support
the protocol for creating nodes and subscribing to them. The nodes,
subscriptions and affiliations are hardcoded in the backend as a
dictionary. Nevertheless, for the most basic uses, this could already be
enough to be usable in embedded systems. In the
Release Often mantra, the current code can be found in the
idavoll2 directory of the idavoll
module in the JabberStudio CVS repository.
No doubt many things will change, but have a look, and let me know what