Roy T. Fielding wrote:
> Aggregators do not consume feed resources -- they consume an
> iterative set of overlapping feed representations.
This is only true of pull based aggregators that poll for feeds.
None of the aggregators that I use are polling based. I use the PubSub
Sidebars and the Gush aggregator built by 2entwine.com. These aggregators
consume streams of entries that are pushed to them using the "Atom over
HTTP" protocol. See:
http://www.ietf.org/internet-drafts/draft-saintandre-atompub-notify-02.txt
As I've said on numerous occasions: "It's about the Entries,
Stupid!" The whole "feed" business is simply an artifact of the
polling-based model of syndication. The Entry should be the core element of
Atom, not the Feed. The Feed, as a collection, is there to serve the Entries
-- not the reverse. Feeds are just a way of bundling up Entries while the
server is waiting for readers to poll for results. But, what readers are
fundamentally interested in is the entries in the feed, not the feed itself.
The polling oriented, feed-based model of syndication results in
significant waste of network bandwidth and processing resources as well as
introducing significant latencies between when items are published and when
they are accessed by readers. (i.e. average latency is 1/2 the polling
frequency.) While the use of push-based aggregators may not be widespread,
it does not make sense, I think, to bind Atom to the inefficient,
high-latency polling model when we know that there is a workable alternative
approach -- which is far superior in at least some important applications of
syndication.
A push-fed aggregator never sees feeds -- except on startup when it
might read a feed in order to catch-up on entries that were published while
it was off-line (if the push server doesn't do guaranteed, queued delivery).
>From the point of view of a push-fed aggregator, a feed is simply a log of
the stream of entries that were pushed to it or would have been pushed to it
if it had been online. i.e. it is a static archive of the dynamic stream.
To touch on another issue recently discussed: A push-fed aggregator,
because it sees streams of entries, not feeds, simply cannot exploit or even
discover any "feed order" information other than pure chronological order.
To require that any significance be given to "order in feed" is essentially
the same as prohibiting the use of Atom in poll-fed aggregators. In a
push-fed aggregator that sees a steam of entries, it is essential that any
inter-Entry relationships be specified within the entries themselves. No
other information is available...
The Atom spec will live or should live for a long time. It would
not, I think, be good to tie it too tightly to the inefficient, high-latency
polling model -- even though that model is the most commonly used today.
bob wyman
