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: Fri, 30 Apr 2004 08:53:08 -0500
To: Alex Rousskov <rousskov@measurement-factory.com>
Cc: HTTP working group <ietf-http-wg@w3.org>
Message-Id: <1083333188.30884.107.camel@bog>


> I would not call the above "random I/O" pattern because you are doing
> a single fetch and a single patch operation as far as protocol is
> concerned. The proposed PATCH method and even existing diff formats
> seem to support the above use case reasonably well.
> 
> Can you think of any reason why PATCH with common diff formats cannot
> support the above efficiently?

I was simply raising this as a possible use-case, and it is encouraging
to hear some initial reports that the existing diff algorithms may be
able to efficiently support these types of operations.

> 
> I was under impression that you are talking about supporting large
> volume of micro updates (e.g., remove a single character in the middle
> of a 100MB file) that must be committed in real time, one by one.
> Doing so efficiently may require mechanisms different than proposed
> PATCH.  However, your example seem to be within PATCH scope! Sorry if
> I misunderstood the true meaning of the "random access I/O" term.

I think large volumes of micro-updates should be efficiently
implementable as well.  One might expect a WebDAV file system driver
operating across a LAN to work in this fashion.  I think as long as you
do without the Content-MD5, and avoid extra copying on the server-side,
you could end up with reasonably efficient large volume micro-updates.

However, semantically speaking, it probably isn't a good idea to PATCH
changes to a file while the file is in an unknown state - so I would
guess something like the write log mechanism might make a lot of sense.

What do the DAV file system driver guys think of this?  Apple?

Thanks,

-Justin
Received on Friday, 30 April 2004 09:55:51 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Friday, 27 April 2012 06:49:30 GMT