Eric Scheid wrote:
I just reviewed the relevant example in the APP spec and it's
worrisome. Reading between the lines it suggests that the
subscription uri is "http://example.org/entries/go", with the rest of
the collection available via rel="next" through to
"http://example.org/entries/10".
The worrisome thing is that once that collection gains another 10
entries, then the resource "http://example.org/entries/11" will now
contain the entries which were previously contained by resource
"http://example.org/entries/10". Every page of the collection needs
to be updated and have the entries shuffled along.
Yes, I have noticed this problem some time ago as well. See
"Directionality of "next"/"previous": Incompatibility with Feed-History
I-D (long)" [1] for some more discussion on this very subject, which led
in turn to PaceReverseLinks [2], which hasn't received much support,
however. :-(
Andreas Sewe
[1] <http://www.imc.org/atom-protocol/mail-archive/msg04645.html>
[2] <http://www.imc.org/atom-protocol/mail-archive/msg04718.html>