Re: More on Paging

> 1.  Next/Prev URIs are not necessary.  The client can just send a 
> sendNext or sendPrev
> command and the server can decide what to send.  Or, the client can 
> request a range
> of items based on a URI template.

The first sounds completely analogous to Sandro's suggestion weeks ago for 
how a server might handle this.  "sendNext" = his next-URI (which simply 
recorded...in the uri... the last value of the key already materialized on 
the page the client already holds).  This should work for any value of 
'key' the server is using, whether or not it is exposed to the client. 
sendPrev is just the same in the opposite direction.

One could also use URI templates for paging, yes, whether or not one has 
the facilities in the current LDP paging draft (they can be viewed as 
orthogonal).  Are you asserting that the use cases are wrong/incomplete by 
bringing this up?  I'm not sure what it adds beyond an implementation 
option.  URI templates at a high level just move the discussion to "what 
are the parameter names" and potentially constraints on the values, from a 
standardization standpoint.  When you suggest a range, that sounds like 
random-access paging, which LDP paging does not address as a use case 
(indeed, this is one I brought up earlier as a common one that is NOT 
addressed; I was not attempting to bring it into scope, being all too 
aware of where it leads based on our implementation experience).


> 4. It is quite difficult to create eTags for the collection to check
> if it has been modified while
> paging thru it.    We discussed various database techniques that may
> help such as System
> Commit Number but none seemed to offer a good solution.

You might have missed this at the end of today's meeting's IRC channel

<JohnArwe>ashok, what is difficult about etags on collections?  is that an 
implementation issue or something general?
<JohnArwe>...I can think of some specific cases where a perfect etag would 
be hard, but a good-enough(?) might not be.
<ericP>JohnArwe, I think Apache does etags over directories
<ericP>Yves, you spec'd that, didn't you?
<TallTed>I'm thinking some of the eTag difficulty may be 
implementation-specific... so such might not be required for 
simple-compliance feature, but I *think* we already said it wouldn't be, 
anyway
<sandro>conceptually I cant see the problem
<TallTed>s/simple-compliance feature/simple-compliance/

I agree with Ted's remark.  As we've talked about etags on the container 
it was always "if the server makes them available, it gives clients who 
care the ability to change tacks."  Some clients in our experience care, 
others not so much.  I'd expect the container to cater to its expected 
clients.



Best Regards, John

Voice US 845-435-9470  BluePages
Tivoli OSLC Lead - Show me the Scenario

Received on Monday, 5 May 2014 15:25:14 UTC