RE: Why MKCOL/PUT can't automatically create ancestor collections ?

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