« Edgio = Open, Craigslist = Walled Garden | Main | PeopleAggregator: Numerical vs. Qualitative Identity »

April 08, 2006


Duncan Cragg

> This reminds me that it really has come time to prepare a formal IETF
> Internet Draft describing RFC3229+feed. It is time that we had something a
> bit more formal than a post on my blog as the documentation for this
> method. If anyone has any issues that should be addressed in such an ID,
> please let me know.

One issue I think would be very important to consider is integration with the Atom Publishing Protocol - as long as you don't get bogged down in the Atom standardisation process!!

Of course, the benefits of this approach go beyond 'mere' saving of bandwidth. You publish an update of some stuff using APP, then subscribers get a delta saying exactly what you've changed and can react according to the content of that delta. This not only saves bandwidth, but helps programmers because they needn't work out the diff themselves. You describe this in the blog entry you refer to (http://bobwyman.pubsub.com/main/2004/09/using_rfc3229_w.html).

Tying in update formats (APP) with event formats (RFC3229+feed) and other publish-subscribe mechanisms is the start of a nice event-driven programming model - it's not just feed update and notification we're looking at, here, but any data that APP is being applied to (and the list of APP-driven applications is growing). Whether deltas are fetched by GET in a polling way, or pushed by POST, or sent by XMPP is irrelevant to the basic model of pub-subbed resource changes - specifically, pub-subbed XML deltas.

Looking further ahead - a World-Wide Web of updating XML resources (linking to each other instead of to HTML), and you've got a dynamic semantic web!

The comments to this entry are closed.