Re: More on Paging

Thanks, John!
Comments inline.
All the best, Ashok
On 5/12/2014 8:41 AM, John Arwe wrote:
> sendNext: if you remember Sandro's proposal, all the state was preserved in the URIs themselves.  There was zero session state kept on the server, so nothing to object to.  These are not the droids you're looking for.
SendNext does require the server to maintain state and is not restful.
The argument is that the server knows if the collection has changed and has
a better chance of sending accurate data.
>
> templates => ranges: if by ranges you mean the trivial case UI folks start with ... I want 20 items/page, and I want the 5th page (b/c I'm currently on page 4 and the user just scrolled down), that's what I meant by random-access paging.  if you mean something else like http range requests, I'm not catching your drift but there are obvious problems there like defining sensible range units; "bytes" isn't very predictable at the RDF level.  You might have to work in terms of >1 line replies there.
>
I was thinking "send me items 30 to 40" etc.
> eTag on a container:  maybe our imprecision has bitten us.
>
> The primary scenario we've discussed is that it's useful for clients to know when *it is possible* they have missed something, because the container definitely changed while they were traversing its pages, and to allow clients to detect this as early as possible during the traversal so they can bail early if need be.  I don't think we've talked about the inverse case, i.e. "if the container etag is UNchanged, does that GUARANTEE that the client missed nothing?"
>
> A simple-minded definition might be "if the RDF model in the response after traversal is not isomorphic to a snapshot taken prior to traversal [regardless of how it is actually implemented, i.e. snapshots are NOT required implementations], then the etag MUST have changed".  Defining it in terms of the response gets complicated once you add filtering and inlining, so defining it in terms of the container's properties including its membership/containership is what I was thinking.  A simple argument being: since the container itself is an LDPC, it's an LDP-RS, and LDP-RS's *are required to have ETags* already (LDP 1.0), if returning that extra (but still existing) bit of info on paging allows clients to be more efficient at a higher level, why not define the syntax for doing so?
The problem was exactly how to create an accurate eTag for the collection.  Merits some discussion.
>
> I don't have a horse in this race, so I'm just letting my Gemini sides argue it out here on the fly.
>
> We'd have to be careful to define the desired output (which changes to the container require its etag to change), since HTTP leaves that determination up to implementations, and we have to consider the inverse membership case too.  As earlier posts have shown, some implementations in that case "store" the membership triples in the members and "compute" them when returning the container's representation.  My suspicion is that we'd say the container's etag must change if any of its (currently 3) subsets of state change... membership triples, contains triples, other triples... regardless of the mechanism involved.  I could see that being hard-er in the computed membership case, especially if members are added without transiting LDP create requests ... i.e. if I can just chuck some new data on the server randomly and as a result the container's (or many containers')  "effective membership" changes, "notifying" the containers in the sense of changing their etags could be 
> overhead - but that's also why I think we've said doing so is optional.
>
> 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>
> Cloud and Smarter Infrastructure OSLC Lead
>