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

> 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

Received on Thursday, 29 April 2004 19:54:48 UTC