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. -- Thomas Broyer
