On Sunday, February 6, 2005, at 07:42 PM, Bob Wyman wrote:
Interesting to hear the architecture for the model that most people use today be referred to as an "artifact". But yeah, to someone who doesn't used polling aggregators, it would seem so.The whole "feed" business is simply an artifact of the polling-based model of syndication.
The "sliding window" view into the historical states of entries (vs. a sliding window into the current states of entries) would also waste some bandwidth transmitting obsolete entry states, and could result in missed entries if someone writing an entry does a lot of tweaking and publishes each tweak (thus filling their feed document with versions of a single entry), which, though sloppy methodology, is probably not entirely uncommon--just my guess. Polling combined with diffs of the current state of entries would use similar bandwidth to push...The polling oriented, feed-based model of syndication results in significant waste of network bandwidth
and processing resources...and wouldn't require the server to keep track of all of its subscribers, and would result in bandwidth usage being spread over time better than push, assuming push servers push new entries out to everyone as quickly as possible after they're published. Both methods have their advantages, many more of which could be listed on either side, I'm sure.
While the use of push-based aggregators may not be widespread,Agreed. But I've lost track of what aspect of Atom's architecture you are saying is bound to polling at the expense of push. Are we still talking about sliding window vs. current state? If so, what difference does that make to a push-based aggregator?
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.
