- From: Lisa Dusseault <lisa@xythos.com>
- Date: Thu, 2 Aug 2001 11:48:15 -0700
- To: "Clemm, Geoff" <gclemm@Rational.Com>, <w3c-dist-auth@w3.org>
I'll second that; it's unnecessary complexity. lisa > -----Original Message----- > From: w3c-dist-auth-request@w3.org > [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Clemm, Geoff > Sent: Thursday, August 02, 2001 7:13 AM > To: w3c-dist-auth@w3.org > Subject: RE: Why MKCOL/PUT can't automatically create ancestor > collections ? > > > 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 14:48:50 UTC