- From: Clemm, Geoff <gclemm@rational.com>
- Date: Thu, 2 Aug 2001 10:13:00 -0400
- To: w3c-dist-auth@w3.org
Yes, no response is usually an indication of lack of interest, but to make it explicit, I personally do not feel that the optimization of auto-creation of ancestor collections warrants the added complexity of having either an "auto-create ancestor" header, or having it be server-defined whether or not ancestor auto-creation takes place. Cheers, Geoff -----Original Message----- From: Steve K Speicher [mailto:sspeiche@us.ibm.com] Sent: Thursday, August 02, 2001 9:23 AM To: w3c-dist-auth@w3.org Subject: Re: Why MKCOL/PUT can't automatically create ancestor collections? I assume that based on the lack of response to my previous posting (http://lists.w3.org/Archives/Public/w3c-dist-auth/2001AprJun/0286.html), that no one is in agreement that I have a valid point/issue. Should I assume this? Thanks, Steve > Re: Why MKCOL/PUT can't automatically create ancestor collections? > > From: Steve K Speicher (sspeiche@us.ibm.com) > Date: Mon, Jun 18 2001 > > ------------------------------------------------------------------------ > > To: w3c-dist-auth@w3.org > From: "Steve K Speicher" <sspeiche@us.ibm.com> > Date: Mon, 18 Jun 2001 09:48:51 -0400 > Subject: Re: Why MKCOL/PUT can't automatically create ancestor collections? > > 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? >
Received on Thursday, 2 August 2001 10:13:34 UTC