ralphm.net

ralphm's blog

Monday, 1 November 2004

pubsub.ik.nu uses Idavoll 2

Eating one's own dogfood...

As of today, the pubsub service at ik.nu is 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 latter for 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 enough.

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 (IPublishService), 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 twisted.protocol.jabber.component.IService interface 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 backend (BackendService) that implements IPublishService and 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.IService, resulting in a component.Service for each backend service.

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 __implements__ attribute of the backend. I didn't want to go there.

Have a look at the code in the Idavoll CVS repository or the generated API documentation. If you have any questions, comments or suggestions, let me know!