W3C home > Mailing lists > Public > ietf-http-wg@w3.org > April to June 2004

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

From: Justin Chapweske <justin@chapweske.com>
Date: Thu, 29 Apr 2004 18:52:10 -0500
To: Lisa Dusseault <lisa@osafoundation.org>
Cc: Alex Rousskov <rousskov@measurement-factory.com>, HTTP working group <ietf-http-wg@w3.org>
Message-Id: <1083282729.30884.96.camel@bog>

> 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

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.


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

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:13:24 UTC