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 09:22:55 UTC