- From: Suma Potluri <suma@soe.ucsc.edu>
- Date: Fri, 4 Aug 2006 00:05:52 -0700 (PDT)
- To: "Julian Reschke" <julian.reschke@gmx.de>
- Cc: w3c-dist-auth@w3.org
Hi Julian, Thanks for your response. I wasn't aware of the earlier draft on PATCH by Lisa Dusseault when I submitted this latest draft. I admit that I should have done a little more research into it before submitting the new I-D. In any case, I noticed that there hasn't been much activity in this area since the past two years. I would be happy to collaboratively work with Lisa Dusseault or anyone else that would be interested in these methods, so that we could get something useful out of this. As for the earlier discussion on the PATCH method, I have a few questions/comments. 1) There seemed to be an extensive debate about using a new header field for the patch format. The way I thought it was that there could potentially be many patch-types with each patch-type working on a set of content-types (one indicated by the 'getcontenttype' property). So each patch-type is mapped to a set of content-types that it would work on. Using the content-type header to indicate the patch-type that would map against a set of content-types seemed confusing. But as I was reading the earlier discussion, there were some convincing objections against using a new header field. If the Content-Type header is the preferred way to define the patch format, we could proceed with that. 2) I also noticed that one of the earlier suggestions was to use the normal diff or diff -e as the required patch format for text files which was what I proposed in the I-D. It is a simple and widely used diff format that could be easily generated by the clients. For binary files we could explore the option of using gdiff as the required diff format. 3) APPEND is a simple and efficient method, since there is no need to be concerned about the patch formats and content-types. For clients that do mostly appends, this could be very useful. I'd be interested to hear comments from the client's perspective with regards to using this method as opposed to the PATCH method. Also I have been working on the mod_dav server and was able to get a working implementation for the two methods - APPEND and PATCH according to the I-D specification. I am planning to do some performance testing to see how these methods compare to the PUT method. If we could reach an agreement on the specification, I could change the prototype accordingly before testing these methods. Again thanks for your comments, -Suma > Hi Suma, > > there's quite a lot of previous discussion on the HTTP WG mailing list that you should review, for instance around the thread > <http://lists.w3.org/Archives/Public/ietf-http-wg/2004OctDec/thread.html#msg4>). > > So I would approach the topic this way: > > - discuss on the HTTP WG mailing list, not here. This is not specific to WebDAV, > > - realize that APPEND is a special case of PATCH, > > - also realize that PATCH itself doesn't need a lot of work. By > submitting a PATCH request a client asks the server to modify the existing resource based on the instructions in the message body. Full stop. > > How the message body is to be interpreted depends on it's Content-Type (so you don't need "Patch-Type" at all). All the spec really needs to specify is at least one very simply diff format, and a MIME type for it. > > Speaking of which I see use cases for at least two patch formats (one for textual diffs such as in the Unix diff command output), and one for modifying parts on binaries (seek/write/etc). > > <http://greenbytes.de/tech/webdav/draft-dusseault-http-patch-04.html> of the PATCH draft actually used that model, and IMHO it was a mistake to move away from it. Quite logically, draft 05 it good serious pushback from Roy Fielding > (<http://lists.w3.org/Archives/Public/ietf-http-wg/2004OctDec/0011.html>). > > Best regards, Julian >
Received on Friday, 4 August 2006 07:06:02 UTC