Subject: PaceFeedState status

From: Tim Bray <[email-masked]>
Date: Mon, 24 Jan 2005 16:17:42 -0800

If there were no further discussion: Like PaceSupersede, this model of 
publishing does not (so far) enjoy consensus support.   -Tim

---

From: Joe Gregorio <[email-masked]>
Date: Mon, 24 Jan 2005 20:09:35 -0500

I am +1 on the //atom:head/atom:link[@rel='prev'], but -1 on
//atom:head/atom:link[@rel='wholefeed'] and -1 on any of the verbage
that makes demands on clients, for example, "Atom consumers MUST warn
users when they do not have the complete state of a feed "

   -joe

-- 
Joe Gregorio        http://bitworking.org

---

From: Antone Roundy <[email-masked]>
Date: Mon, 24 Jan 2005 19:54:30 -0700

> users when they do not have the complete state of a feed "
Agreed, agreed and agreed.

"When a new Atom Feed Document is received by a consumer, the entries 
in it are compared to those that are already known to belong to the 
same Atom Feed, in reverse document order (that is, starting with the 
last entry in the Atom Feed Document and working towards the first). If 
an entry from the document has the same 'id' attribute as an existing 
entry, the metadata associated with it replaces that currently 
associated with the entry completely. Any existing metadata, whether or 
not present in the new entry, is removed."

I think this is beyond the scope of the specification.  First, the 
"reverse document order" part is unnecessary and inappropriate.  
Second, the client may keep the history of an entry--we shouldn't be 
mandating that the old metadata be discarded.

"By following such links progressively backwards and incorporating the 
changes in each associated Atom Link document, until it encounters a 
link to a document it already has seen (as identified by the 
//atom:head/atom:link[@rel='this'] element), a consumer can reconstruct 
the state of a feed reliably."

I'm not sure I'm in favor of this method.  If, for example, the 
"sliding window" into one's feed contains 15 entries, and the "prev" 
link points to the prior 15 entries, unless one polls when a multiple 
of 15 entries have been added, you'll never see the same batch of 
entries you saw last time.  Of course, feeds could be implemented in a 
way that avoided this problem...and I'm not sure I can think of a 
better method off hand.  If for example you were to keep going backward 
till one saw an entry/id they'd seen before, you might stop too early 
if an entry had been altered and moved nearer the top of the feed.  If 
you were to try to avoid this mistake by checking entry/updated for a 
change, you could still fail if the publisher decided not to bump its 
value (I for one would not change the order of entries without changing 
updated, but that's not to say others won't).