Re: PATCH, gdiff, and random-access I/O

That's great, I see now we're on the same page, except that a new diff 
format ought
to be a completely separate standard from PATCH.  I'd also recommend 
that
somebody who really needs this first investigate to see if the local 
I/O log can
in fact be translated into gdiff (or other existing diff format) -- in 
which case
PATCH could already handle the use case.

Lisa

On Apr 29, 2004, at 4:52 PM, Justin Chapweske wrote:

>> I also have my doubts about random-access I/O support.  The 
>> HTTP/WebDAV
>> model is to do whole-resource operations, and since PATCH is all in 
>> one
>> method that still qualifies.  With WebDAV support, a client would be
>> advised
>> to LOCK the resource and GET it, perform random-access I/O on the 
>> local
>> copy, then PUT/PATCH and UNLOCK the file.  Without WebDAV support,
>> client should do the same but using ETags rather than locks.
>
> The random-access patterns that I am suggesting would still operate as
> an atomic whole-resource operation and using ETags could be implemented
> very efficiently.
>
> To give a motivating use-case, lets look at a memory and storage
> constrained embedded device which wishes to access and modify some
> resource that is larger than the available local storage.
>
> This device may access some subset of the resource via Range requests,
> and then may perform a number of random-access-style I/Os on the
> resource.
>
> One reasonable implementation might be to keep an I/O log of all of the
> operations that were performed on the resource.  Once the device is
> finished with its modifications, the PATCH method would be issued with 
> a
> payload that is basically a replay of the local I/O log.  This approach
> mitigates the need of the embedded device to store any information 
> about
> the original state of the file because it need not do a comparison 
> after
> the fact.  Additionally, the storage/memory requirements are directly
> proportional to the number of new bytes written to the resource and
> waiting to be flushed.
>
> Again, I think the PATCH proposal is a good one, I'm just a bit nervous
> that there aren't enough diverse use cases to make it applicable to a
> large set of problems.
>
> Thanks,
>
> -Justin
>
>