Re: More on Paging

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.

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.

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? 

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
Cloud and Smarter Infrastructure OSLC Lead