Re: I-D for WebDAV methods - APPEND and PATCH

Suma Potluri schrieb:
> 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

That's correct, and it's completely OK to start a new take on getting 
this method defined. It's just that there is a lot of useful discussion 
in these email threads.

> 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

General remark: I think it's not a good idea to base this on WebDAV. 
This is a generic HTTP problem, and if the solution depends on WebDAV in 
any way, that's problematic. On the other hand, it would be ok to have 
appendices discussing on how these messages relate to WebDAV, versioning 
and ACLs.

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

You simply have to do that. RFC2616 *mandates* that when you send an 
HTTP message, the Content-Type header defines the type of the content. 
That's what it's for.

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

True. Again, the method definition should just state that the path 
format is defined in the Content-Type header. This gives you all the 
extensibility we need (text diff, binary patches...).

The single issue with this spec (that eventually brought the previous 
attempt to a halt) is that there seems to be agreement that the spec 
should require at least one simple (!) patch format, and that needs to 
have a MIME type (either already defined or defined by this spec), and 
that needs to satisfy the IPR requirements of the IETF.

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

OK, here's an example:

Instead of saying:

         APPEND /~suma/index.txt HTTP/1.1
         Host: dav.cse.ucsc.edu
         Content-type: text/plain

         Testing Append
         Hello World Again!!!

Just use:

         PATCH /~suma/index.txt HTTP/1.1
         Host: dav.cse.ucsc.edu
         Content-type: text/entity-append

         Testing Append
         Hello World Again!!!

And then let the spec define the MIME types for "text/entity-append" 
(appending to a resource with text/* MIME type) and possibly 
"application/entity-append" (binary).

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

I understand that the prototype implementation is an essential part of 
your project, and it's definitively useful to test it in practice, but 
of course proper specification is what the people over here are more 
concerned with...

Best regards, Julian

Received on Friday, 4 August 2006 07:37:37 UTC