- From: Stefan Eissing <stefan.eissing@greenbytes.de>
- Date: Thu, 17 Feb 2005 17:34:02 +0100
- To: Cyrus Daboo <daboo@isamet.com>
- Cc: Julian Reschke <julian.reschke@gmx.de>, CalDAV DevList <ietf-caldav@osafoundation.org>, Mark Baker <distobj@acm.org>, "Roy T. Fielding" <fielding@gbiv.com>, WebDAV <w3c-dist-auth@w3.org>, HTTP Working Group <ietf-http-wg@w3.org>
Am 17.02.2005 um 17:05 schrieb Cyrus Daboo: > Hi Julian, > > --On February 17, 2005 2:54:38 PM +0100 Julian Reschke > <julian.reschke@gmx.de> wrote: > >> 1) CalDav's approach is: use PUT to an arbitrary member URI of the >> container; then let the server automagically move it somewhere else, >> and >> report that in the Location response header >> (<http://greenbytes.de/tech/webdav/draft-reschke-http-addmember >> -00.html#r >> fc.section.A.2>). > > I want to add that in the CalDAV case this URI naming restriction will > also apply to COPY and MOVE methods too, not just PUT. So we do need > to come up with a solution that at least works with those methods too. > Of course it is possible to emulate COPY and MOVE using PUT (client > downloads original data, creates it in new location) and DELETE > (remove old data in the case of MOVE) - but we should really have the > proper atomic operations for this. It seems to me that however you solve the PUT/ADDMEMBER/POST problem, it can be used to solve the MOVE and COPY scenarios as well, at least for single, plain resources: PUT/ADDMEMBER/POST a new, empty resource -> 201 with Location COPY/MOVE to that new Location Would this work? //Stefan
Received on Thursday, 17 February 2005 16:35:08 UTC