PATCH, gdiff, and random-access I/O

Related to this, does the gdiff format allow you to succinctly describe
a remote random-access write type operation?

It seems to me that there will be two main ways in which PATCH will be
used:

o The traditional diff/patch approach where complete copies of the old
and new versions of the files are compared to extract a diff.  The diff
is then PATCHed to the HTTP resource.

o Real-time edits and random-access I/O ala NFS.  It should be simple to
express actions such as:

  - Write bytes at a given offset, including scattered writes

  - Append to the end of a file (already covered)

  - Skip beyond the end of the file and write some bytes, leveraging
support for file system "holes" if supported by the server.

  - Truncate the file to a given length, including 0. (already covered)

I would guess that some WebDAV clients that are implemented as file
system drivers may tend to prefer the second approach, especially if
operating over low-latency networks.

This brings up another issue.  With the second style of PATCHing, the
suggestion that "   The server SHOULD provide a MD5 hash of the content
after the delta
   was applied.  " becomes very onerous indeed since a bunch of small
writes to a huge file will result in an unacceptable performance hit.

In any case, I think it is important that the specification recommend a
delta format that can meet the needs of both diff/patch type usage as
well as remote random-access I/O patterns.

Thanks,

-Justin

> 
> I meant that you could change the size of a resource without resending 
> its existing content. For example, to truncate a resource to just the 
> first 100 bytes of its current content, this gdiff command could be 
> sent:
> 
> 	0xd1, 0xff, 0xd1, 0xff
> 	4
> 	249,0,0,100
> 	0
> 
> Extending a resource without resending its existing content can be 
> accomplished with a gdiff copy command (to copy the existing resource 
> content) followed by a data command with the new data to be appended.


-- 
Justin Chapweske - Founder, Onion Networks
http://onionnetworks.com/
651-340-8787
 
Transfer large files 10x faster than FTP with Onion Networks' WAN
Transport(tm).  http://onionnetworks.com/products_wantransport.php

Received on Thursday, 29 April 2004 18:11:07 UTC