Sunday, 28 November 2004
Just a little note on avatars and Jabber. In x-virge's Jabber Vision, there's a piece on the need for Idavoll to be finished and deployed for finally implementing avatars in the Jabber universe, the right way. Though publish/subscribe is an essential element of the Avatar JEP, there's another dependency: discovery.
In particular, a client has to discover a contacts pubsub node by sending a Disco request to the contact's bare JID. The idea is that the contact's Jabber server responds to this request, and for it to do that, the contact first has to publish this information to its Jabber server. This process is also known as disco-publish. However, as far as I know, jabberd 1.4.x doesn't support disco-publish, and jabberd 2's support is flakey, last time I checked. That covers a big part of the installed base of Jabber servers. How is the support in other servers?
is going strong. I can say it is now in a state that should be usuable
for developing applications with. A while back, I asked pgmillard what features of
should be implemented, for Idavoll to be deployed on the
jabber.org public Jabber server. I believe all of his
requirements have now been met. Here the list of supported
Creating nodes (including so-called instant nodes)
Subscribing and unsubscribing
Publishing items + subscribers getting notifications
Requesting a previously published item
Retracting a previously published item
Purging all items for a node
Deleting a node
Configuring a node
Requesting current affiliations
Disco Info and Disco Items support
Some notes on the above:
Subscription requests are always automatically accepted; owner approval using Data Forms is not yet implemented.
The only two node configuration options (for now) are whether the node is persistent, and whether notifications should be sent with or without payload.
Disco Items is only implemented on the service itself, for requesting all nodes present. There is no hierarchy in the nodes in the current implementation. Because this will generate a lot of data when having more than a few nodes, this functionality can be disabled by the administrator of the service.
Despite the notes, the service should be more than sufficient to finally start implementing all sorts of cool publish/subscribe based features in Jabber clients. More on that in a bit.
What might hold people back in deploying Idavoll right now, is that there is no simple drop-in package, yet. Part of the problem here is that the Jabber support in Twisted needs some patches here and there. One of the patches is stringprep support for JIDs, a must-have, as was pointed out to me by [GNU], earlier today. So I've been busy implementing stringprep support today. And it works!
Twisted development is in a state of flux, as their upcoming 2.0 release will probably be split up in several packages, and the Jabber modules have been moved around. Also, dizzyd, who wrote the Jabber support for Twisted is busy with non-Jabber stuff, and I have to somehow get my patches in Twisted's codebase. I'll try and coordinate this with dizzyd in the coming week or so. In the meanwhile, I'll probably have to distribute my patches to Twisted along in the Idavoll release, but I am not sure how to go about that, yet. For now, just checkout the code from the CVS repository, and give it a whirl. I will be more than happy to do some hand-holding.
Today, x-virge wrote an interesting piece on his blog about his Jabber Vision. Intented as some guidance in fixing the biggest pain points currently perstering Jabber, he goes and explains what should be done to get Jabber back up to speed.
One of the things he mentions is finally having a usuable pubsub server component, combined with not one, but two encouragements to help out with finishing Idavoll. Thanks x-virge! I'm not sure if he agrees with my statement above that people could start using Idavoll now for developing their cool stuff, but I can definitely use some help in testing the code, and making it even more useful. If you are interested in helping me out, drop me line!
Monday, 1 November 2004
As of today, the pubsub service
powered by Idavoll
2. This means that I think the Twisted rewrite of
Idavoll is now good enough to support Mimír and the pubsub features of
this site. A nice milestone.
The current implementation has two different backends, one that
stores all data in memory, and one that has persistent storage using
PostgreSQL. I use the
pubsub.ik.nu. This backend is very
limited at the moment. It only supports publishing items, storing the
items (if the node is so configured) and notifying subscribers.
Creating nodes, setting up subscriptions and configuration of nodes is
done by updating the database. But that should change soon
I am now at a point that the basic architecture of Idavoll is becoming stable enough to quickly implement new features. I have struggled a bit with finding out how to best use interfaces and adapters in Twisted, and spiv, on the #twisted IRC channel helped me go in the right direction.
The easy part was this: I splitted up the (optional) features of
JEP-0060 in nice chunks that are represented in several backend service
interfaces. That way, people can code backends with different storage
mechanisms and/or business rules, while only having to implement the
parts that are useful for the application at hand. So, there is one
interface for publishing items (
one for subscribing to, and unsubscribing from, a node
ISubscriptionService), and so on.
Next, I wanted to split up the Jabber protocol implementation along
similar lines. These would be implemented as adapters from such a
backend service interface to the
for implementing subservices of a Jabber server component. The problem
with this is that you would want to have one backend class implement
the choosen interfaces and then instantiate a
component.IService with an instance of that backend
class. And you can't do that, because it is ambigious!
Taking the two interfaces described above. Suppose I implement a
BackendService) that implements
ISubscriptionService, and I have adapters to
component.IService for both of them. What does the following do?
import my_backend import pubsub from twisted.protocols.jabber import component ... backend = my_backend.BackendService() service = component.IService(backend) ...
As I said, this is ambigious. This could yield either adapter
for the implemented backend interfaces. So, what I did was
still implement the code for the backend in one class that is
MultiService, and have skeleton child services that state the actual
interface that is implemented and pass on the method calls to their
parent. That way, you can simply call for the adapter from these
child service to
component.Service for each backend
This probably isn't going to win any beauty contests, but it
was the result of my discussion with spiv. Other approaches were
even less desirable. I could define all adapters to be incremental
and have only one
component.Service per specific
backend. Another approach would be to have some code that figures out
which adapters to fire up from the
attribute of the backend. I didn't want to go there.