- From: Julian Reschke <julian.reschke@gmx.de>
- Date: Tue, 08 Aug 2006 10:27:36 +0200
- To: Jim Whitehead <ejw@soe.ucsc.edu>
- CC: edgar@edgarschwarz.de, w3c-dist-auth@w3.org
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
Received on Tuesday, 8 August 2006 08:27:49 UTC