Yes, the paging in APP is a problem (one I've been largely ignoring up to this point in our own implementation). There is no way of reliably and efficiently reconstructing the entire feed history.
- James Eric Scheid wrote: > On 1/5/06 5:55 PM, "James M Snell" <[EMAIL PROTECTED]> wrote: > >> That said, however, we end up with a >> problem when we have one spec that says next points backwards in time >> (APP), one spec that says next points forwards in time (feed history) >> and one spec that says next is just another page of entries that match >> some criteria (opensearch). No matter what the various link types point >> to, there needs to be consistency. As it stands now, a single feed >> cannot implement APP, OpenSearch AND Feed History. > > 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. > > A simplified example: > > /entries/go contains entries Q,R,S,T > /entries/2 contains entries M,N,O,P > /entries/3 contains entries I,J,K,L > /entries/4 contains entries E,F,G,H > /entries/5 contains entries A,B,C,D > > which then gets another 4 entries added (ie. U,V,W,X) and the collection now > looks like this: > > /entries/go contains entries U,V,W,X > /entries/1 contains entries Q,R,S,T > /entries/2 contains entries M,N,O,P > /entries/3 contains entries I,J,K,L > /entries/4 contains entries E,F,G,H > /entries/5 contains entries A,B,C,D > > This is just smells bad in so many ways. Pity the blog package that > publishes static files and will have to rebuild every collection page. Pity > the poor server that gets asked if /entries/3 has been modified and if so > hand it over. Pity the google bot that does all that asking. > > > Of course, this sentence doesn't parse into English real well either: > > "next" and "prev" link elements reference the > preceding and subsequent feed documents in the set. > > ie. "next" references the *preceding* feed document, and "prev" references > the *subsequent* feed document. It doesn't even make sense when read Down > Under ;-) > > e. > >
