Skip navigation

Okay, it’s not really a dispute. That was sarcasm in the title. Just to be clear, since there’s always been a tiny bit of useful friction between the idea of XMPP and web hooks, it’s important to remember they are not mutually exclusive. Anybody hyping a battle between the two is trying to create or is imagining a controversy that isn’t real. Many proponents of web hooks are XMPP proponents as well. In fact, the video some are pushing around to promote this supposed throw down is of two XMPP supporters (including djabberd author Brad Fitzpatrick) demoing a pubsub system based on web hook callbacks. And it takes place at an XMPP meetup, so of course there was going to be some proselytizing.

Nevertheless, Jabber/XMPP is a messaging protocol. Web hooks provide a model for functional extensibility, so they are a platform for many different things. A push-based pubsub messaging system is just one use. Even though I originally wrote about web hooks as a notification mechanism, my mind was nowhere near pubsub. I was more focused on the idea of web service integration and orchestration. With the commoditization of CGI-enabled web hosting, I was thinking about how the popularity of web programming combined with the easy invocation of HTTP requests could be used to make a more useful and functionally extensible web. A more programmable web.

With that said, there is nothing wrong with discussing what you can and can’t do with web hooks and XMPP, but there is not some angry fight between camps. Done. Over. Moving on.

As it turns out, the project demoed in that video, which is called pubsubhubbub, is something I had previously stumbled upon while browsing projects a friend of mine was involved in. There wasn’t much of a description, and I didn’t dive too deep into the code, so I bookmarked it to come back to it. After that demo happened, it seemed I misheard (from several people) that it was some XMPP pubsub system, which totally confused me because… it’s not. It’s a neat, distributed pubsub implementation built on web hook callbacks created by Brad Fitzpatrick and Brett Slatkin (a Google App Engine developer). Hopefully they’ll put some more documentation up as it develops, but it’s just really neat to see some XMPP folks build an open pubsub system with web hooks. Cheers to them!

5 Comments

  1. Indeed, that was an interesting “dispute”… And I agree 100% that we actually need both. From a user’s perspective, it’s not the “pipe” that matters but the data!
    Anyway, As far as I understood PubSubHubhub is more like SUP (friendfeed’s protocol) in its “concept” than like XEP-0060!

  2. I think I can see that, but the major thing that makes it different from SUP is that it actually has a callback or hook mechanism that means you can actually be triggered or pinged instead of having to poll yet another feed.

  3. Fantastic thoughts, Jeff. A friend and I were talking about which architecture to use for building a notification system that sends out multiplatform alerts (e-mail, SMS, IM, RIA) when my web site gets updated, so of course we talked about XMPP or web hooks. We tried to base the decision in terms of the total labor involved…which is the rub.

    The CMS I use is a third-party product that, with the exception of an RSS 2.0 feed (not Atom), there’s no public API and thus no event framework to tap into. I’d have to write a hacky workaround to emulate the publishing event (if at all possible) and wire-up the callbacks with web hooks.

    Or, setup an entire XMPP infrastructure with a PubSub or PEP backend and build a custom bot to listen to changes and then push out updates.

    I’m partial to go the web hooks route on this one, but ironically, the amount of work to do either in this situation would be about the same: a lot. :-)

    Thoughts?

  4. Jason,

    You don’t mention whether you actually have access to the code, but if you do, the core mechanism for invoking a web hook is usually a single line of code in most environments. The rest of the work is just managing the callbacks for what, but if it’s a one-off solution for yourself, that makes it much easier to ping out to one endpoint in all cases, which you can just hardcode… making the end implementation literally one line to have the real-time push mechanism in place.

    From there you just write the code to take that data and push it to whatever protocol/channel you want. When it’s a one-off solution for yourself like this… it’s pretty straightforward to get something working with web hooks.

    However, if you don’t have access to the code and there is no event API, you can use something like Gnip to turn the RSS feed into a callback (they use web hooks to push data).

  5. Thanks! With my CMS being a web-based platform, we theoretically *could* modify the underlying system, but I think we negate our support terms…meaning if something goes awry I’m on my own (and it’s in Perl, which is outside my C# knowledge).

    That’s great advice though…thank you!


Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: