Does atom:updated apply to *this* feed document, or the whole,
logical feed?
On 24/08/2007, at 1:06 AM, Daniel E. Renfer wrote:
Would it be safe to assume that if I retrieve two pages of a paged
feed,
and the atom:updated element for the feed is unchanged then I am
indeed
seeing a complete history of that feed?
If I retrieve page 1, record the updated time, and retrieve page 2 and
the updated time has changed, then I know new entries have been
added to
the feed since I got page 1. There may be some entries in page 2
that I
previously saw in page 1. (The ones that have overflown to the next
page) I'll have to re-retrieve page 1 to get the new entries.
If I retrieve page 2 first, and then get page 1, and the updated value
has changed, I know that I am missing some entries. They were on
page 1
when I first got page 2, but are now on page 2. (or higher) I will
have
to re-retrieve the next page(s) until I find an entry I recognize.
If the updated value is unchanged, then nothing has been added,
removed,
or modified in the feed. I can consider my view of the feed to be
complete.
Am I correct in this assumption?
Thomas Broyer wrote:
2007/8/21, Nikunj Mehta:
Thomas Broyer wrote:
2007/8/21, Nikunj Mehta:
§10.1 of AtomPub I-D expects collection partial lists aka pages
to be
/lossless/.
Seems like we don't have the same definition of lossless then...
Allow me to clarify. A lossless paging is the following (this is my
interpretation of §10.1 of AtomPub I-D):
The partial list of entries obtained by GETting the
collection's URI
combined with partial lists obtained by following the rel="next"
links in each of those partial lists MUST provide the
snapshot of
all of a collection's entries *as of the time *when the server
responded to the GET request on the collection URI.
OK, so we don't have the same interpretation. It means this means
clarification in the spec (is it too late?).
On the contrary lossy paging occurs when there is no such guarantee,
i.e., navigating between partial lists might produce the same entry
twice or more, might skip an entry completely because it
"disappeared in
the boundary between pages".
Yup.
Partial lists in AtomPub are subject to the following constraint:
The first such partial list returned MUST contain the most
recently
edited member Resources and MUST have an atom:link with a
"next"
relation whose "href" value is the URI of the next partial
list of the
Collection. This next partial list will contain the next
most recently
edited set of Member Resources (and an atom:link to the
following
partial list if it exists).
If I am interpreting this right (without any formal model of
course),
then "next" implies the immediately "next most recently edited".
To me,
that means lossless.
As partial lists are not defined to be "stable", they might be
changing over time. At the time you retrieve the first partial list,
the second partial list contains the "next most recently edited". But
between the retrieval of the first partial list and the time you
retrieve the second one, this one might have changed.
I respectfully disagree with this interpretation per my argument
above.
If the definition of partial lists and paging results in collection
feeds being lossy, then how would we guarantee any
synchronization of
paged collections?
You cannot guarantee synchronization without an atomic operation or
paging a snapshot. Requiring servers to create "paged
snapshots" (i.e.
as per your interpretation of atompub-protocol-17) would have too
much
implications: servers would need to remember each and every "edit"
(app:edited) of all the entries.
The "partial list" thing is the Simplest Thing That Could Possibly
Work. If you want a reliable synchronization, then either:
1. use another mechanism (RFC3229 w/ Feeds?)
2. re-start synchronization from the Collection URI partial list
until you no longer need to follow the rel="next" link
Sorry I have come a little late to the feed history I-D party,
but it
looks like this spec is not strongly consistent with AtomPub (and
the
fact that the two don't even refer to each other's existence
stinks, IMHO).
Furthermore, can someone point out which RFC or I-D defines link
rel="first", link rel="last", link rel="next" and link
rel="previous"?
http://www.iana.org/assignments/link-relations.html says its Feed
History.
--
Mark Nottingham http://www.mnot.net/
