Re: Clarification on MKCOL needed

Thanks for the quick response.

Greg Stein wrote:
> 
> Is it possible for you to create (internally) the server-specified
> collection and then somehow link/alias the Request-URI to point to the
> new collection?

It's problematic because we are trying to make use of a legacy
repository that has some inconsistencies with the WebDAV model and we
are trying not to modify the repository code.  In particular, if you use
the repository-assigned ID's of the objects in the repository for the
URI, then you can have proper URI's for each object, but you can't
create new collections with MKCOL for the aforementioned reason.  If you
use the user-assigned name of each object in the repository, you can't
have proper URI's for each object in the repository because there can be
multiple objects in one collection that have the same name.

After thinking about your suggestion, it appears we have two choices. 
We could use the user-assigned names of collections in the MKCOL
request-URI and also assign the new collection a URI based on the
repository-assigned ID's.  Or, perhaps a better approach would be to
consider it a flaw in the repository that two objects in the same
collection can have the same name and just disallow access via WebDAV to
all but one of the objects with the same name.

> If you have a custom client, then you can define a method such as
> "STARBASE-MKCOL" which is modelled after MKCOL, but returns a Location
> header with the true URI. Another alternative is to return the
> "next-collection-name" as a property of the parent collection; this has
> transactional problems, though (e.g. what happens if two clients request
> the property and then use it in MKCOL?)

That is problematic indeed in our case.  I think I'd rather bend my
product to work with the protocol than extend the protocol to work with
my product.

Thanks again.

-- 
Brian Stiles

Received on Friday, 10 September 1999 19:47:29 UTC