XMPP, AtomPub and microblogging
Following my previous posts about my work on mixing AtomPub and XMPP together in a single application I’ve worked yesterday on the basic workflow of the application I write.
The first use case is to create a profile using OpenID.
- When landing on the application main page the user can enter his (or her) OpenID which will redirect him to his OpenID provider for validation.
- Once validated and accepted the user comes back to the application which shows a simple profile page pre-filled with information using the simple registration extension of OpenID.
- Upon submitting his profile for registration the application stores the profile following the format described in XEP-0154. It also creates a node in a Jabber PubSub service that will be used as the top-level node of the user. It finally creates a workspace specific to the user within the AtomPub service.
Note the the application I’m writing will conflate two similar notions into one and make them context free:
Both terms will refer to a channel in the application. So sub-nodes of the user top-level node will be called a channels and each collection within the user workspace will also be called a channel. In other words publishing data to a channel means publishing data to both the PubSub node and the AtomPub collection at the same time no matter the protocol chosen to perform the operation. The channel convention is arbitrary but helpful as it hides the underlying protocol away.
Once a user is registered to the application he can log in using his OpenID. After logging in the user can register, start and stop the internal XMPP client associated with his account. The first step is to register it from the application. Once registered the client can be started and stopped at will.
When the internal XMPP client is registered the user ought to use his favorite Jabber client to register a new account to the Jabber server. Then he should subscribe to the internal client’s contact list that will automatically accept it (probably in a better scenario subscription should be moderated from the user’s profile page).
The second use case is to create channels
- The user could create channels using either his Jabber client or using the AtomPub interface.
- In both cases the application would create both the according PubSub sub-node to the user’s top-level node and the appropriate AtomPub collection.
The third use case is to publish data to channels with XMPP
- The user uses his own Jabber client to send a message to the internal jabber client like this: â€œpublish channel Hello world”. This would translate into â€œPublish ‘Hello world’ to channel” where channel is the name of the channel to publish to.
- The jabber server would forward this message to the internal client who upon parsing it would understand it must publish the sent data to the according PubSub node. First it would enclose the data into the atom:content of an atom entry and publish that entry as the node’s item.
- When the item is published the Jabber server would send a notification back to the internal client which could then create and store the according AtomPub member entry to the appropriate collection. The entry would become visible via the Atom feed of the collection.
Note that waiting for the notification to be propagated back to store the atom entry within the collection rather than doing it immediately when publishing to the PubSub node is not gratuitous. Indeed the user could publish items directly from an external client that understands PubSub. By doing it the way described above we ensure that even in such a case the internal client will be informed a new item was published to a node it is subscribed to and therefore the application will keep in sync’ no matter what.
The fourth use case is to publish data to channels with AtomPub
This would be similar to the previous use case except the entry point would be the AtomPub interface and that of course a message would be sent through XMPP accordingly.
Deleting items from channels would work in the same fashion.
Of course the user’s channels would then be publicly available and other users could subscribe to the Atom feed, to the internal XMPP client or to the user’s PubSub nodes.
From there on the application could be extended so that for instance users can comment to each other and ensure that the channels’ items contain that information, for instance using RFC 4685 within each item.
These are few things I’ve been working on. The application is not ready yet and it might take a few days for it to complete and hopefully some of you will be interested in testing it then.
Regarding the platform used, Python and the following products:
- headstock through Kamaelia for the XMPP layer
- amplee for the AtomPub interface
- CherryPy 3.1 for the HTTP serving
- amara for the XML handling