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. >
signature.asc
Description: OpenPGP digital signature
