W3C home > Mailing lists > Public > w3c-dist-auth@w3.org > July to September 2006

Re: PATCH MIME types, was: PATCH delta: dsfantf1

From: <edgar@edgarschwarz.de>
Date: Sat, 26 Aug 2006 22:51:01 +0200 (MEST)
Message-Id: <200608262051.k7QKp1m3013059@post.webmailer.de>
To: w3c-dist-auth@w3.org
Cc: edgar@edgarschwarz.de

Julian Reschke <julian.reschke@gmx.de> wrote:
> thanks for the proposal. However, it's not easy to read. Perhaps you 
> also have some simple real-world examples?
It's supposed to be sort of EBNF. Not more complex than your XML stuff I think :-)

> 2) A format that can transport simple changes to binary files, such as 
> replacements, truncates and appends (that format may be useful for 
> WebDAV clients that act as file system drivers),
With dsfantf1 (And probably also other binary diff formats).
replace:
	copy 0 to before replacement from source,
	copy replacement from delta,
	copy after replacement to end.
truncate:
	copy 0 to truncation point from source
append:
	copy 0 to last from source
	copy tail from delta
	
> The simplest approach for 2) seems to define a new (binary) format that 
> can capture POSIX file I/O operations on a byte stream (truncate, seek, 
> write, additionally perhaps "copy range from source"). 
As you can see you only need "copy from source" and "copy from delta".

> We may want to 
> also define a profile that allows streaming (that is, disallows seeking 
> back from the current position).
My given operations don't allow seeking back in the created resource.
truncate, seek and so on only make things more complex IMHO. They e.g. don`t
allow a simple replace with a different number of bytes.

> From a procedural point of view I think it would be best to define 
> these formats in separate documents, and let the PATCH spec just refer 
I disagree. For PATCH to be of any value at least one mandatory
delta format should be given. A binary format is enough.

So just define e.g. two operations:
   copy from source: offset, number of octets
   add from delta : number of octets, octets
So the replace operation e.g. could be:
c 0,12345 CRLF
a 10 CRLF
<10 octets> CRLF
c 5, 123456789012345 CRLF    # skipped 5 octets and append rest of source.

Do you really want to make a separate document for that ? Without at least
one general mandatory delta format PATCH doesn't make sense. So please keep
it together.
Anybody who wants to have more can define his own stuff.
Do you see any problems for implementors with these two operations ?
What fundamental features do you feel are missing ?

Cheers, Edgar
Received on Saturday, 26 August 2006 20:51:23 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 2 June 2009 18:44:15 GMT