Web Hooks User-defined HTTP callbacks for push, pipes and plugins

Replies to This Discussion

Permalink Reply by Laurence A. Lee on August 31, 2009 at 10:04am

As a very active Ruby developer with a personal library of assets written against the Dojo Toolkit, I've been partial to Comet as a means to accomplish this.

▶ Reply to This

Permalink Reply by Konstantin A Lukin on August 31, 2009 at 10:25am

Have not used Comet, but looks like major difference is that Comet is a client-server library. Web hooks is not a library, but a design pattern applied to solve HTTP push problem. A possible (proposed) implementation is to have a RESTful webservice that accepts client callbacks. Client provides a callback URL with initial request. When new data arrives, webservice notifies client by calling specified URL. In this model, there is no client library, just a regular webservice call.

This could be very useful as a way to 'hook' into webservices all over the web and listen to real-time updates with some user specified HTTP script, which could be written in any language.

Laurence A. Lee said:

As a very active Ruby developer with a personal library of assets written against the Dojo Toolkit, I've been partial to Comet as a means to accomplish this.

▶ Reply to This

Permalink Reply by Konstantin A Lukin on September 8, 2009 at 7:31am

As part of HTTP push callbacks research, came across this interesting post about HTTP keep-alive and COMET. It dives into details about what happens with both, and pros/cons on using them.

http://markmail.org/message/fym6uhhgsdw6zqzj

▶ Reply to This

Permalink Reply by Laurence A. Lee on September 8, 2009 at 8:15am

Agree with the technical details of the article -- HTTP 1.1 keep-alive has nothing to do with Comet. Keep-alive is a way to allow the Browser/Server reuse a socket to exchange multiple assets like Stylesheets, JavaScripts, etc. Old-Skool HTTP 1.0 didn't have keep-alive, and thus a complex web page would hammer the Server for each and every Asset, and then close the sockets after the asset was received. Very wasteful...

The article makes several arguments against Comet that are only applicable in a pure AJAX/Web Browser context, and some of those arguments are somewhat outdated. I doubt they'd affect any competent Software Architect choosing to design around Comet today. For example, a common trick to get around the "2 sockets per host" limitation is to use multiple hosts, or at least multiple host names like "www.myhost.com" and "asset[0..9].myhost.com". In fact, that technique is so commonplace that Ruby on Rails has built-in support to declare and use Asset Hosts in that manner. :-)

Comet, at its core, traditionally works on "Long-Polling" Sockets. I think LPS is superior to Web Hooks, as the Client (Web Browser) end is the one initiating the Socket Connection. The reason why it's superior is because such sockets can work across Proxy Servers, as well as behind Firewalls or NAT Routers. A Server cannot hit a "Callback URL" unless such obstacles are removed.

Comet apps typically use the Publish/Subscribe model, which essentially boils down to Message Queues maintained by the CometD server. You can go from simple things like IM/Chat systems, to complex RealTime Data Updates. And since Comet is really just a protocol, you're not limited to Web Browsers as clients. RIA platforms, Java, and .NET can also be made to play well.

About a year ago, I was collaborating with a guy doing an application on a Dual-Monitor setup -- on the primary monitor was an AJAX app; and on the secondary monitor was MS-Word, controlled by a Comet listener written in .NET. As focus changed in the AJAX app, the web browser updated its own context, as well as pushed a Comet message to have MS-Word load the corresponding document. :-)

Not that I'm not dismissing Web Hooks.. just advocating Comet as a useful technology.

▶ Reply to This

Permalink Reply by Konstantin A Lukin on September 8, 2009 at 8:47am

This is great, thanks for this post, Laurence! It sounds like Web Hooks and Comet have different applications, both are quite useful. Since Comet is just a protocol, are there 'recommended' implementations, possibly for multiple languages? It would be great to see a detailed article (maybe on TechHui? :) that goes over how Comet works, possible usage scenarios, example code, implementations, etc..

▶ Reply to This

Permalink Reply by Laurence A. Lee on October 21, 2009 at 8:13am

Just a follow-on to this discussion... I came across a recent announcement about Comet in Nginx that does a nice job of explaining Server-Push, and provides sample code.

▶ Reply to This

▶ Reply to This