I don't know how to interpret this - does Atompub draft have a bug, or
is it intentionally underpromising. Looking at it in the context of
answers I have heard from folks on this topic, it is the latter.
Also, it just feels like anyone implementing Atom should consider RFC
5005 in conjunction with the Atompub spec, lest they be misled into
thinking what "next" means.
Oh, and BTW, I did not know if paging meant fixed size paging. I hope
that is not another implicit assumption everyone's making.
Nikunj
Joe Gregorio wrote:
On 8/27/07, Nikunj Mehta <[EMAIL PROTECTED]> wrote:
In that case, how can you correctly interpret rel="next" as "paged feed"
allows lossy feed paging and "collection feed" requires lossless paging?
Sorry, but the feed paging in AtomPub is "lossy" if you follow the definition
of "lossy" in RFC 5005:
"""Paged feeds are lossy; that is, it is not possible to guarantee that
clients will be able to reconstruct the contents of the logical feed
at a particular time. Entries may be added or changed as the pages
of the feed are accessed, without the client becoming aware of them.
"""
That is, if I break my paged AtomPub feeds into pages of 10 entries
each and if client A is trying to do a sync and client
B edits an old entry in the middle of the process then it is possible
that client A will miss some entries. For example, if my site has 20 entries
broken into two pages:
Page 1 [e0, e1, ... e9]
Page 2 [e10,e11,...,e19]
If client A requests Page 1 and shortly after client B
edits e11 then we get:
Page 1 [e11, e0, e1, ... e8]
Page 2 [e9, e10,...,e19]
When client A requests Page 2 it will miss e11. It will
also see e9 a second time. If I were writing a client
and wanted to make sure I got a good sync I would
finish a first pass at the sync and then go back to the
beginning and do a sync again until I saw an entry I
recognized, in this case e0.
-joe
