Re: snapshots, was Re: Stable locking

Hi Sandro:
Yes, snapshotting can be useful for purposes other than paging.
Some databases offer a "flashback" capability that allows you to
go back to a previous version of a table to recover from errors, etc.

But for paging I had a somewhat different design in mind.
Assume that we design a prefer header that may have values "snapshot"
or "rolling" where rolling gives you the current state of the collection
even as it changes from underneath you.

When a request comes in with prefer=snapshot, the server makes a copy
of the collection and its members.  It then serves those pages. When the
client moves away from the collection the snapshot is deleted. Thus, the
snapshot is created on demand only for a specific paging request.

Ashok

4/7/2014 2:54 PM, Sandro Hawke wrote:
> On 04/07/2014 11:29 AM, Ashok Malhotra wrote:
>> Some of our developers have also been struggling with the paging issue.
>> In the discussion one potential solution has emerged which may be worth considering.
>>
>> When a client accesses a collection and starts to page thru it, the server makes a copy
>> of the collection (snapshot).  It then serves that client from that snapshot.  The snapshot
>> is deleted when the clients commits or aborts.
>
> Yes, I called this "static" or "snapshot" paging.
>
> But this is something one wants with or without paging.  It's a general thing that one wants a web server to do.   And it can be quite expensive to provide.  So I suggest(ed) we keep it orthogonal.
>
> That is, some servers provide the feature where they allow clients to snapshot a resource, and use that snapshot for some time. This would be useful for paging, certainly.
>
> This is applicable outside of LDP. http://www.w3.org/TR/ldp/ has a snapshot that's been http://www.w3.org/TR/2014/WD-ldp-20140311/ for some time.  For a while before that, the snapshot was http://www.w3.org/TR/2013/WD-ldp-20130730/ .
>
> One simple design for this would be a Link rel=snapshot header. The server could include that link on any resource for which it's willing to provide a snapshot, and the link would point to that snapshot.    The actually text of link would probably include the timestamp or the etag.   Or a version number.
>
> This design has the advantage of being very simple, but it has some weaknesses.    For resources that will have many versions that are never snapshot'd, it's more expensive for the server than necessary, because the server needs to some work on every request, not just ones where the client wants to snapshot.   That could be addressed with a Prefer: make-snapshot request from the client, I suppose.
>
> Another weakness is it doesn't provide a way to get a consistent snapshot of multiple resources, such as a container and its contained resources.   The simplest protocol I can think of for that is to allow adding a timestamp to the Prefer: make-snapshot.     So the client would say
>
>     Prefer: make-snapshot date="Mon, 07 Apr 2014 14:48:24 -0400"
>
> But that requires the server to be able to reconstruct the previous states of resources in the recent past.     For my applications that might be a reasonable thing to require of the server, but it's still a lot.     Probably better to let a multi-resource snapshot wait until there's a clearer use case, where we can see how much server implementors would be willing to do.
>
>
>     -- Sandro