- From: Brian Stiles <bstiles@starbase.com>
- Date: Fri, 10 Sep 1999 16:47:53 -0700
- To: Greg Stein <gstein@lyra.org>
- CC: w3c-dist-auth@w3.org
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