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

PATCH MIME types, was: PATCH delta: dsfantf1

From: Julian Reschke <julian.reschke@gmx.de>
Date: Sat, 26 Aug 2006 12:41:17 +0200
Message-ID: <44F0254D.6060502@gmx.de>
To: edgar@edgarschwarz.de, w3c-dist-auth@w3.org

Hi Edgar,

thanks for the proposal. However, it's not easy to read. Perhaps you 
also have some simple real-world examples?

Related to that I spent some more time thinking at what formats are IMHO 
desirable:

1) A format for specifying text diffs,

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),

3) potentially a patch format for XML.

Of these, 1) and 2) are well understood and probably simple to implement 
on the server-side. Now a specification of a PATCH format has reduced 
value if the client can't rely on some formats everybody understands. 
Does this mean that we would want to require support for 1) and 2)?

Requiring an XML patch format on the other hand IMHO would be premature, 
and probably not acceptable for a general purpose server.

So how do we get 1) and 2)?

The simplest possible approach for 1) seems to be writing down a concise 
description of the simple diff format, as created by the original Unix 
diff program (see 
<http://www.opengroup.org/onlinepubs/000095399/utilities/diff.html>). I 
think we could get away with defining our profile of that format, and 
then refer to the ISO or IEEE spec. A precedent for that approach is 
RFC3339 (which describes a profile of ISO8601).

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"). We may want to 
also define a profile that allows streaming (that is, disallows seeking 
back from the current position). If I would have to define the format, 
I'd probably model it similarly to the HTTP chunked encoding format 
(http://greenbytes.de/tech/webdav/rfc2616.html#rfc.section.3.6.1) -- 
"plain text" instructions interleaved by binary content.

 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 
to them.

Best regards, Julian
Received on Saturday, 26 August 2006 10:41:33 GMT

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