Atom over XMPP

Finally! Now that Sam Ruby‘s sent it to the atom-syntax mailing list and Mark Pilgrim‘s b-linked it people are finally *finally* beginning to take notice of this.

I genuinely think that this is the most exciting thing you could possibly want to do with Atom.

stpeter, ralphm and Bob Wyman (and probably others) have been working hard on getting pubsub into a workable and working state, developing software that uses it, and feeding back into the spec process. It’s been a joy to watch.

I already have a hacked version of Syndirella which I use that uses pubsubxmpp to connect to’s XMPP delivery service (via JEP-0060) and then parse the Atom content using Atom.NET and provides the items to the user completely transparently. It just looks like any other feed except that it’s updated by push, not pull, and is updated in real time – when a new article is published, that’s when I’m reading it.

(Ideally I think I’d have a hacked version of FeedThing to do this instead, just because it would mean an app that could actually redraw without me noticing, but that would mean dusting off my c++ and I’m not quite that desperate yet. 😉

This is a big step towards my perfect aggregator. In fact, if Atom starts supporting the concept of a “read state” on items then I could implement a proper distributed aggregator system using Atom over XMPP as its core extremely easily.

I can’t wait.

Oops, stpeter points out that I should also have credited pgmillard, who actually wrote the pubsub spec! Sorry about that Peter!

Published by

5 thoughts on “Atom over XMPP”

  1. Why not open an HTTP listener and use an HTTP POST request with an Atom feed as the content body?
    You wouldn’t need a sourceforge project to write a client – there are lots of httpd listeners out there in many languages.

  2. You wrote: “Why not open an HTTP listener and use an HTTP POST request with an Atom feed as the content body?”

    This won’t work for most users whose desktop clients are behind firewalls and thus can’t receive HTTP POST requests from machines on the other side. One key benefit of using XMPP comes from the fact that it establishes a persistent connection from the desktop machine to the PubSub server which tolerated by most firewalls.

    An alternative HTTP-based solution would be to use the HTTP persistence in the manner of mod_pubsub or the products of . But, accepting incoming HTTP POSTs is just not an option for most folk.

    bob wyman

  3. Thanks for that Bob – you got there before I did!

    It’s also important to realise that XMPP isn’t just a layer for transporting arbitrary XML data. XMPP explicity defines things like presence and availability, and servers provide store-and-deliver mechanisms, none of which are available in conventional HTTP communications.

  4. nice to see that someone uses my library 🙂

    Can you tell me when the thing will be ready and publicly available?


Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.