Is APPEND really needed ?

julian.reschkegmx.de 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

edgaredgarschwarz.de schrieb:
> ...
> 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 
> ...

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

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

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.

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

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

> Con:
> * method is more complex: implementors need to
implement mandatory 
> 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

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:

>
> edgaredgarschwarz.de schrieb:
>> ...
>> 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 
>> ...
>
> 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 <h
ttp://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
>