Re: Tools that make use of previous/next/first/last links?

[James M Snell <jasnell@xxxxxxxxx>]

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" <jasnell@xxxxxxxxx> 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.
> 
>