Joe has fleshed-out his description in Bloom Filter Resources. Great stuff. Note that this can be generalized for any kind of “cool URI” (finite identifier set) update checks by using the URI path as key.

That said, sites are free assign SUP ids by any method of their choosing, including URI hashes, so in practice this extra flexibility only makes things easier for SUP producers.

The SUP tag/header also provides for discovery of which URIs provide updates, and where those updates are published. This allows sites to publish multiple SUP feeds or even contribute to a shared feed published elsewhere.

In any case, these solutions are very similar. The real differences are in the mapping function’s persistence, discovery of what URIs are monitored for updates, the representation format for update notifications, and the use of a single feed URI versus a template of separate resources. Each choice has trade-offs.

If you’re interested in discussing any of these ideas further, please email me paul @ friendfeed.

Personally, I would suggest changing it to two streams — one with the full feed and another with just a URI and single-line title ending with a linefeed character. The latter is all that an event broker needs and is much easier to parse than Atom XML. Alternatively, an XMPP stream would be appropriate for small summaries published to many consumers, especially if you could convince someone else to broker the subscriptions (e.g., it would be a good demonstration stream for Jabber).

Not saying it is the right solution, it certainly needs modernizing, but it works quite well for what we’re needing to do.

HTTP, XMPP, and SMTP are just tools — we should use whichever one best fits the deployment environment and interaction style. We should choose them based on rational design comparisons and actual data transmission needs, not paper tigers.

I agree that the problems that they solve can be thought of as roughly similar, but the differences in implication for event notification systems are more than slight.