- From: Steve K Speicher <sspeiche@us.ibm.com>
- Date: Mon, 18 Jun 2001 09:48:51 -0400
- To: w3c-dist-auth@w3.org
Sorry about the delay on the response... "Jim Amsden" wrote: > I think the reasoning was the same for PUT, PROPPATCH, etc. You don't want > the server creating namespaces as the side effect of an operation. MKCOL > and DELETE make namespace manipulations explicit. This prevents erroneously > typed URLs from creating spurious namespaces. > I don't understand how making these explict will cause anything other than forcing a bunch of overhead. Take for example, in a client app the user decides to do a "Create file with path: 0/1/2/3/4/5/6/7/8/9/foo.c" The client app has the options of: a) Performing the PUT and seeing what the status code is. If it is 409, then client can then attempt a MKCOL on each parent collection until one is successful. Once successful, then traverse back down the path and perform each MKCOL, then perform the PUT. b) Performing many PROPFIND's (either starting from the root or from the file resource), then perform a MKCOL for each collection and then finally the PUT. Does the client app have to prompt the user whether each collection should be created? How does forcing the client app to perform all these operations prevent erroneously typed URLs from spurious namespaces? My app does a large amount of *implicit* namespace creation and I'd like to do a simple: PUT /0/1/2/3/4/5/6/7/8/9/foo.c HTTP/1.1 and have the parent collections implicitly created if they don't exist but the spec forces the overhead mentioned above. Could this server behavior be advertised using the DAV header with something like "auto-collections"? Then if one so desired, removing the requirement that "PUT operation creates a new non-collection resource all ancestors MUST already exist" (RFC2518 8.2.2) if auto-collections is supported and making the method MKCOL an optional feature. I'm not sure this requirement is consistent with DELETE, MOVE, and COPY: which can perform a large amount of namespace manipulation in one METHOD (namely on a parent collection). There is no way to guarantee that the new target destination URL has not been erroneously typed other then by user inspection after the fact (or by client app prompting, do we ever pay attention to those ;-) Thoughts? Thanks, Steve
Received on Monday, 18 June 2001 09:44:17 UTC