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

From: "Clemm, Geoff" <[email-masked]>
Date: Thu, 2 Aug 2001 10:13:00 -0400

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:[email-masked]]
Sent: Thursday, August 02, 2001 9:23 AM
To: [email-masked]
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 ([email-masked])
> Date: Mon, Jun 18 2001
>
>
------------------------------------------------------------------------
>
> To: [email-masked]
> From: "Steve K Speicher" <[email-masked]>
> 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?
>

---

From: "Lisa Dusseault" <[email-masked]>
Date: Thu, 2 Aug 2001 11:48:15 -0700

I'll second that; it's unnecessary complexity.

lisa

> From: [email-masked]
> [mailto:[email-masked]]On Behalf Of Clemm, Geoff
> Sent: Thursday, August 02, 2001 7:13 AM
> To: [email-masked]
> Subject: RE: Why MKCOL/PUT can't automatically create ancestor
> collections ?
>
>