ralphm's blog

JSF Council 2004 Position Paper

Following the nice example of both pgmillard, and stpeter, this is my position paper for the Jabber Council.

Background

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.

The Council

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.

Why me?

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.

Posted at 12:51 by ralphm #.

Tune

Prompted by Intosi's questions about using Bonobo for getting information out of Rhythmbox, I got curious myself.

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 on ralphm.net, let me know.

Posted at 13:11 by ralphm #.

Maintaining the Jabber World Map

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!

Posted at 14:38 by ralphm #.

Idavoll rewrite (continued)

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 requests.

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 of 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 Early, 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 you think.

Posted at 17:08 by ralphm #.