On Monday, February 7, 2005, at 12:00 PM, Bob Wyman wrote:
In order to demonstrate polling at its most efficient, I defined andYou are of course the one in a position to know about this. I'm curious though--do you have figures on how much push reduced bandwidth use vs. RFC3229+feed? My guess would be that the difference wouldn't be as dramatic as between feed and RFC3229+feed, but I recognize that I may be wrong. That guess is what I was expressing.
convinced a number of folk to implement RFC3229+feed. This HTTP extension
eliminates the problem with sending multiple copies of messages to people
and the resulting drop in bandwidth requirements for those who poll and use
RFC3229+feed was dramatic[1] -- however, the RFC3229+feed service still
consumes more bandwidth then the push service. Once again, this ain't
theory, it is experience.
It doesn't sound particularly weird, though I don't understand why the typical client would feel the need to see obsolete representations of entries that had been changed more than once while they were offline. I fully agree that we should not lock out the option of including multiple instances of an entry in some kind of Atom Document. But I also don't think that we should require all Atom Documents (other than Entry Documents) to do so. In other words, I don't think this is an either-or question--I think both should be possible.There are several "Feed-oriented" or "polling oriented" discussionsI've lost track of what aspect of Atom's architecture you are saying is bound to polling at the expense of push.
going on:
1. The requirement that feeds not be permitted to contain multiple
entries that have the same atom:id. This requirement prevents push based
system from using feeds as "logs" or "histories" of messages sent. For
instance, at PubSub, the Atom file which is associated with every
subscription contains a stream of entries that are the entries that either
were or would have been sent to the client if it had been connected. The
first thing a client does on starting up is to read the Atom file in order
to synchronize state with the server. Thus, the feed is actually just a
trace of the messages sent. This probably sounds weird if you're
feed-focused; however, it makes perfect sense if you are pushing entries.
2. Significance of the order of entries in feeds. A push-fed client
only sees feeds in edge cases (like the PubSub synchronization usage
discussed above). Because a push-fed client receives a stream of entries --
not feeds, it can only see chronological order unless order is encoded
within the entry itself. Any requirement that document order is significant
(and some are still suggesting it is) means that a push-based system must
push entire feeds rather then individual entries. The bandwidth costs of
doing so would be completely unacceptable.
Agreed.
3. The absence of a revision id or atom:modified. The feed-istsMakes sense. I personally have come to like the idea of using dc:modified rather than defining atom:modified. (I am a proponent of atom:updated because there is no Dublin Core equivalent for it).
don't see the need for revision numbers in part because they are focused on
feeds rather than entries. If you live in the world of entries -- as a push
system does -- then the need to distinguish multiple versions of the same
entry becomes much, much more important.
