Re: paging in editor's draft

> 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
Tivoli OSLC Lead - Show me the Scenario