AtomPub and XMPP

There has been quite a lot of discussions around the use of XMPP in a web context and how to blend HTTP and XMPP protocols for a better social network experience.

I’ve been working on implementing XMPP for a while now on my spare time and even though it’s been a much slower effort I would have liked, I’ve been able to have a fantastic fun with it. Most recently I’ve started integrating XMPP PubSub along with AtomPub using my AtomPub implementation, amplee.
The idea is to use amplee as an AtomPub library from within XMPP PubSub handlers. For instance I map AtomPub collections to PubSub nodes . When an atom entry is published to a node and that the client receives an acknowledgment of that publication, the handler uses amplee to store the entry in the AtomPub collection as well, respecting of course the RFC specification. Similarly if an item is deleted, the handler uses amplee to remove the entry from the collection. This works both ways, we can also run an AtomPub web service which issues the right XMPP stanzas according to the operation carried. So a POST on a collection would publish the atom entry to the XMPP server. The web service would obviously expose the Atom feed of the collection.
This is just a stub, but the idea here is to associate both protocols so that they cooperate to expand the audience of your network. It’d be easy to consider allowing people commenting to a blog entry using their XMPP client. You blog entry would for instance advert the XMPP service and node name where to publish items. The user could then subscribe to than node and publish items.
That’s one reason why I had written amplee as an AtomPub library that could work outside of the HTTP protocol. RFC 5023 defines the protocol using HTTP but the root idea behind it works well in the context of XMPP and maybe AtomPub is the protocol that will rule them all.

amplee 0.6.0 released

As per today’s announcement. I’m glad to release amplee 0.6.0.
This release is an important move from previous releases as it doesn’t include support for any HTTP layer out of the box anymore. The reason is that it made the previous API needlessly complex and stopped people to actually use amplee for what it aims at being: one simple representation of the AtomPub protocol server side. Basically I wish amplee was used as a library rather than as a host for AtomPub applications.

The 0.6.x branch will focus therefore on polishing the AtomPub model API as well as the related sub-packages such as the index and graph extension. Moreover I would like to improve the performance of amplee although they have already improved since 0.5.x. The graph sub-package is a first stab at using graph theory via the igraph package to perform foxy manipulations of Atom feeds.

One major change since 0.5.x is the move from bridge to Amara to parse, query and generate XML documents within amplee. I think that change was for the best considering the capabilities of Amara.

Another change is that I’ve dropped the INI file format for configuration and loading an amplee structure. Instead you can now directly use the XML service document itself and complete using a bit of extra code. That allows for some funny capabilities such as mirroring existing AtomPub service document (see the example directory for instance).
I would like to thank Eric Larson and Mohanaraj Gopala Krishnan for their feedback and patience. They have provided the project with a tremendous help.