Friday, 30 July 2004
Following the nice example of both pgmillard,
this is my position paper for the Jabber Council.
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
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
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
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
Thursday, 22 July 2004
Are you seeing what I'm hearing?
Prompted by Intosi's questions about using Bonobo
for getting information out of Rhythmbox, I got curious
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
The C function for this is called
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
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
I should really automate this...
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
To the client authors: you are doing doing a terrific job. keep
up the good work!
Sunday, 11 July 2004
Presenting what's there already...
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