Re: proposal on ISSUE-94 ("lossless paging")

On Mon, Mar 24, 2014 at 4:25 PM, Sandro Hawke <sandro@w3.org> wrote:

> (continued from telecon)
>
> PROPOSED: Change LDP paging to no longer be characterized as "lossy".
> Specifically, a client who pages all the way through (forward or backward)
> MUST be sent every triple in intersect(g0, g1, ... gn) and MAY be sent any
> triples in the union (g0, g1,  .. gn), where Gi is the paged graph at the
> time client makes request i.   Servers MAY refuse to serve any page because
> they don't want to implement this kind of paging in certain cases; if they
> do so, they MUST return a 410 GONE.
>

I also tend to agree with Ted that we are conflating of two concepts. From
a transaction point of view, what is important is the consistency. So as a
client, I would be happy to get either g0 or (may be any of gn) but not
mixing triples from different Gis. I agree with Sandro that a single HTTP
operation acts like a transaction and HTTP does not allow few triples from
a ongoing PUT to be visible in a parallel GET. However, paging involves
multiple HTTP GETs and in between there could be PUT operations that finish
with success (not partial PUTs), So as soon as we mix triples from
different Gi with interactions and unions, I think we don't have isolation
anymore. To put in another way, if we consider reading through the
complete representation of a resource via paging as a single READ, and PUTs
in parallel as WRITEs, those operations can no longer be put to
a serializable schedule. So I don't think we can say we have isolation.

I think we are in 'Read committed' level. Because PUTs and other write
operations act as request-response single operation transactions, any data
that the client sees is a result of a committed transaction. I think this
fits the description of Read committed, *"**read committed is an isolation
level that guarantees that any data read is committed at the moment it is
read. It simply restricts the reader from seeing any intermediate,
uncommitted, 'dirty' read. It makes no promise whatsoever that if the
transaction re-issues the read, it will find the same data; data is free to
change after it is read."*

IMHO, clients are normally interested in seeing a consistent representation
of the whole resource at any given time but not a mix of different times.
So I personally prefer if we had a way to get a snapshot of a complete
representation to page through.

Best Regards,
Nandana