Mike Rooney (Awn Extras developer, among other things) posted an article on this "webhooks" idea. As I understand it, it's essentially a customizable, web-based version of the "Subscribe to future XYZ via email" features (e.g., blog comments) that are currently around. The key phrase in this sort of thinking is "push technology". Mike asks:
So will webhooks replace the current paradigm that I'm using here, or complement it?
I believe that it will complement the current paradigm. We need to have a transitional period (à la the old, rigid deadline for the US digital television transition) between the current "polling" techniques and the "new and shiny" (and arguably bandwidth-saving) push techniques. Take, for example, Twitter [1]. Let's assume that they didn't shut down their XMPP service, and they built upon it an (XML-based) API so that a client (for the purposes of this thought experiment, let's say my currently-in-vaporware Status Aggregator Awn applet) could connect to a specific JID (AKA user name + domain + "resource", or specific client) and listen for any new tweets, responses to my tweets, etc., replacing those messy timeout callbacks with messy async socket callbacks. The main benefit that I see is a savings in bandwidth for both the consumer and the producer. It avoids sending network requests every X minutes, which would add up, given the number of services/feeds that a user subscribes to (including mail). This actually leads me to my answer to Mike's other question:
Are webhooks the next step of this evolution, or something else entirely?
As evidenced by my thought experiment, I'd like to see XMPP as the next step, or at minimum, the step after webhooks. While I love HTTP, and am a big fan of the whole REST concept, it's hard for me to see it used as a facilitator for pushing data, as opposed to pulling it. In fact, given the way that ETags and the like are designed, HTTP is inherently a pull technology. The Comet model feels like a big kludge to me for that reason. XMPP, on the other hand, is designed to be a push technology, and its supporters are actively marketing it as such. It's also scalable, as servers like ejabberd and services like Google Talk can attest. I suppose the bottleneck here is a catch-22: you need both services and apps to buy into this particular implementation. Maybe when I finish one of the myriad projects I have going at once, I'll take a crack at adding a push-based web service client. Ideally, for configuration, all a user would have to do is set their app-specific JID (e.g. foo@example.com/bar_app) in both the web app and the client app, and it would "just work" (well, you would also have to set the JID password somehow as well, but that's beside the point).
Update (2009/02/18): It seems that I was subconsciously channelling a presentation on XMPP PubSub that I read over six months ago.
| [1] | I'm focusing on the one I actually use. Yes, I should be using identi.ca, since I am a supporter of free and open services/protocols. It even has the hallowed XMPP interface to microblogging. One of these days, I'll do what all the cool kids™ are doing and post to both. It'll probably happen when I (continue) work on the vaporware [2] mentioned above. |
| [2] | It's vaporware until I push the source code onto a public server. |
Posts
2 comments:
I like your suggestion that webhooks are part of a progression towards XMPP-based pushing. I agree that there is a lot about HTTP that is designed for the pull case -- what's more is that the mental model in the vast majority of web programmer is setup for the pull case. While the success of webhooks so far suggests that HTTP is pretty flexible, the fact that they are only becoming visible now attests to how much programmers like their existing paradigms.
I predict that the PRESENCE aspect of XMPP will be very useful when people get around to linking up services with XMPP message passing. I think you'd like to know (even before you've got a message to send) if some add-on component of your service is alive and available. In hooks-land, you don't know until its too late that the other end isn't there. Yeah yeah, if stable production sites only post to other stable production sites then you can sorta sweep this issue under the rug, but not having a clear answer for what it means when the other end doesn't answer (or doesn't answer the way you'd expect) means mashups will always be on shaky ground.
When end users start getting hit by the Push Revolution there is going to be a big divide between those people who can easy accept posts natively and those who have to employ weird workarounds to get messages delivered to them. With XMPP this is solved up front because messages for user@host are delivered via server-to-server protocols and the average user isn't expected to have the ability to accept random incoming connections.
We could address these issues for webhooks with conventions for poking hook consumers with are-you-alive?-I'm-just-curious messages that don't count as delivering data (but this would fly in the face of the "just post all of your data to the url" scheme for the general idea of hooks) and making big aggregator/router/proxy thingies for firewalled users to connect out to for hooks to be accepted on their behalf (but then the fact that the proxy responded one way doesn't assure you that the client would respond that way if you hit them directly). But let's not make this part of our roadmap for certain.
Yeah, let's get hooks out there to GET PEOPLE THINKING PUSHY, but let's not say its the end-all solution when we have an existing protocol that comes with some great solutions. Once you get "web application architecture" types thinking with push message, THEN you can tell them about XMPP. Until then its protocol soup.
Loovely post
Post a Comment