- From: Lisa Dusseault <lisa@osafoundation.org>
- Date: Mon, 14 Aug 2006 17:35:59 -0700
- To: Suma Potluri <suma@soe.ucsc.edu>
- Cc: "Julian Reschke" <julian.reschke@gmx.de>, w3c-dist-auth@w3.org
On Aug 4, 2006, at 12:05 AM, Suma Potluri wrote: > > 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. That would be great. I've been letting the PATCH document languish waiting for some broader consensus for a resolution to the question of what Content-Type means. That's the essential difference between patch draft -05 and draft -06. The changes made to 06 were inspired by Jeff Mogul; I find his entity/instance model elegant in its resolution of a few modeling problems, even if it wasn't how HTTP was initially intended to be modeled. However, Roy Fielding has objected to draft -06 and to Mogul's model and I didn't see a clear consensus which way to go. Lisa > > 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 Tuesday, 15 August 2006 00:36:25 UTC