Re: paging in editor's draft

to me, the whole idea that there is some "natural order" to a collection leads to all kinds of false assumptions. a collection is a set, so there is no such thing as "inserting in the middle of it". if you model collections as sequences, i think you'd end up with rather different interaction models in a variety of places. the fact that the set is served paged is just an interaction model, and my guess is that real-world LDP implementations might very well support different sort keys (as many feed services do), so that clients with different application goals can consume pages that fit their needs. but again, that only matters for the retrieval interactions through the paged access model. assuming the ability to "add something to a page" sounds utterly wrong to me. cheers, dret.

On 31 Oct 2013, at 14:54, "Ashok Malhotra" <ashok.malhotra@oracle.com<mailto:ashok.malhotra@oracle.com>> wrote:

If we allow inserts in the middle of a collection then even next/prev can change out from under you.
All the best, Ashok
On 10/31/2013 2:54 PM, John Arwe wrote:
> John, is it that much of a performance benefit not make all pages
> doubly-linked?

I would not think next/prev is a big deal.

Subtler problem is the use of "last", which I think has semantics likely to surprise people.  I "hear" a finality about last, but in really it's a moving target in many cases.  "Last" was only "last" when the server sent the response; if you retrieve the same "last page" URL again, it might not be "last" any longer.  Flip the page order, and first has the same problem.  Familiar enough behavior to RESTifarians [waves gratefully to ErikW], but I've already seen my share of devs who still come at things with a more traditional (closed) mindset.

I do think it somewhat likely that servers are likely to have some "natural order" that they expect clients to traverse in, probably specific to the resource and/or its type; to some degree this aligns with the whole "first...last" HTTP link header language that originated with Feed Paging and Archiving (RFC 5005).  I'm not so sure that in *all* those cases the opposite order is just as easy to populate, but I don't have any handy examples where I know it's hard (nor honestly have I had time to give it serious thought).  5005 is much more open at this point than LDP, to the degree we consider that precedent relevant: it requires at least one of the links, and (lower case) should's "as many as are practical and applicable".

I do note (looking at RFC 5005) that it defined a "complete" feed [waves again to ErikW], since the concept of completeness arose in the 200/209/303 discussion.  [spoiler alert] Completeness there depends on a single document scope.

[5005 paged feeds] http://tools.ietf.org/html/rfc5005#section-3   is all of 1.5 pages, so not scary to actually read.


Best Regards, John

Voice US 845-435-9470  BluePages<http://w3.ibm.com/jct03019wt/bluepages/simpleSearch.wss?searchBy=Internet+address&location=All+locations&searchFor=johnarwe>
Tivoli OSLC Lead - Show me the Scenario