Subject: Is APPEND really needed ?

From: [email-masked]
Date: Mon, 7 Aug 2006 00:33:43 +0200 (MEST)

[email-masked] wrote:
> >> 7) BTW Is APPEND really needed? Surely a PATCH can do the same thing
> > (except that PATCH cannot create a new resource)?
> > 
> > It is true that PATCH can do the job of APPEND as well. But the APPEND
> > method is much simpler and can be applied to any resource without being
> > concerned about the resource type and the Patch-Type. Assuming that a
> > client need to do mostly appends, this method comes in handy without the
> > 'baggage' associated with the PATCH method. Also it is more efficient to
> > implement at the server and may have a quicker response time. 
> I don't see how it's easier to specify or more efficient to execute than 
> the format I proposed in my other mail.
After reading the discussion for a couple of days now I'm still not at ease
with APPEND.
A new HTTP method which sometimes behaves like a PUT and sometimes like a PATCH
would be a muddy design IMHO. If like Julian proposes this convenience is also
possible with a content type, why not ?
Taking a purists stance I could even drop that :-) A good diff will accomodate 
appending.
I will have to implement one method less in my server and also the RFC will
be shorter without APPEND. There will only be a lot of stuff just duplicated.
This said I'm very happy to see that a standard for sending diffs is discussed
again. Because it really doesn't make sense to send a complete big document
to a DeltaV server if you only correct a single letter typo :-)

Cheers, Edgar

---

From: Julian Reschke <[email-masked]>
Date: Mon, 07 Aug 2006 09:04:20 +0200

[email-masked] schrieb:
> ...
> ...

Maybe it should also be mentioned that that lot's of people are really 
uneasy about defining new HTTP methods. PATCH has the nice property that 
it's not really new, it just needed a proper definition (so keep in mind 
that if you call something PATCH, it really should be identical or 
similar to what already has been described in 
<http://ftp.ics.uci.edu/pub/ietf/http/history/draft-ietf-http-v11-spec-01.txt>.

APPEND doesn't have this property. Furthermore, it's just a "convenience 
  method", because you can alway define a PATCH request that does 
exactly the same.

Best regards, Julian

---

From: Jim Whitehead <[email-masked]>
Date: Mon, 7 Aug 2006 16:14:31 -0700

One rationale for a separate APPEND are filesystem-like clients  
(WebDAV file system drivers, for example) that want to be able to map  
filesystem append capabilities onto WebDAV. This provides a simple  
method that allows them to do this. Append is one scenario where  
WebDAV filesystems perform very poorly as compared to alternative  
network filesystems.

Authoring clients are the primary target for PATCH, as they have  
knowledge about fine-grain changes to resources. AFAIK, WebDAV file  
system drivers don't typically have enough information to send an  
update and use PATCH for sub-file changes.

Could you make append functionality part of PATCH? Sure. The  
tradeoffs are, as I see them:

Append as part of PATCH:

Pro:
* one method
* fewer methods to implement
* fewer methods for access control, configuration

Con:
* method is more complex: implementors need to implement mandatory  
append, text, and binary patch formats
* no longer possible to implement just append capability on its own

- Jim

---

From: Julian Reschke <[email-masked]>
Date: Tue, 08 Aug 2006 10:27:36 +0200

Jim Whitehead schrieb:
> 
> One rationale for a separate APPEND are filesystem-like clients (WebDAV 
> file system drivers, for example) that want to be able to map filesystem 
> append capabilities onto WebDAV. This provides a simple method that 
> allows them to do this. Append is one scenario where WebDAV filesystems 
> perform very poorly as compared to alternative network filesystems.

I agree with that, but I think the problem is not just append, but also 
seeking and truncating. APPEND only fixes one of these cases, where a 
PATCH format can fix all of them.

> system drivers don't typically have enough information to send an update 
> and use PATCH for sub-file changes.

Sorry? A file system driver usually has to map a set of write 
operations, such as seek, write, truncate, so we just need a patch 
format that can transport this information, such as 
the-one-published-as-a-note-by-the-W3C (I recommend not to look at it 
unless it becomes clear that there isn't IETF-unfriendly IPR attached to 
it).

> append, text, and binary patch formats

Well, I guess we would have two (file op, text patch) mandatory patch 
formats rather than one. I don't see how this is worse than having two 
methods instead of one.

> * no longer possible to implement just append capability on its own

Aha, you want to make those independent? In this case just let all patch 
formats be optional.

Even if I would buy the reasoning for a second method, I'd still make it 
more powerful so that it can do a sequence of seek/write/truncate as 
well (in which case it wouldn't be called "APPEND" :-)).

Best regards, Julian

---

From: Lisa Dusseault <[email-masked]>
Date: Mon, 14 Aug 2006 17:29:22 -0700

I agree with this.  One could even define a custom "delta format" (an  
algorithm for applying a patch) that only did appending, use it with  
PATCH, and then one would have the simplest way of achieving APPEND  
without duplicate specification.

Lisa

On Aug 7, 2006, at 12:04 AM, Julian Reschke wrote:

> Maybe it should also be mentioned that that lot's of people are  
> really uneasy about defining new HTTP methods. PATCH has the nice  
> property that it's not really new, it just needed a proper  
> definition (so keep in mind that if you call something PATCH, it  
> really should be identical or similar to what already has been  
> described in <http://ftp.ics.uci.edu/pub/ietf/http/history/draft- 
> ietf-http-v11-spec-01.txt>.
>
> APPEND doesn't have this property. Furthermore, it's just a  
> "convenience  method", because you can alway define a PATCH request  
> that does exactly the same.
>
> Best regards, Julian
>