Re: paging in editor's draft

* John Arwe <johnarwe@us.ibm.com> [2013-10-31 14:54-0400]
> > 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.

Another cost of "last" is that one cannot freeze the content on one
server and move to another, which was one of the motivators for the
initial LDP Submission. We could say that "last" is "last known". I
outline this option under '=case for "last" as "last known"=' in
<http://www.w3.org/mid/20130924074607.GF29518@w3.org>.


> 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
> 

-- 
-ericP

office: +1.617.599.3509
mobile: +33.6.80.80.35.59

(eric@w3.org)
Feel free to forward this message to any list for any purpose other than
email address distribution.

There are subtle nuances encoded in font variation and clever layout
which can only be seen by printing this message on high-clay paper.

Received on Friday, 1 November 2013 02:11:57 UTC