Date: Mon, 10 Apr 2000 23:24:32 -0400 (EDT) Message-Id: <200004110324.XAA10259@tantalum.atria.com> From: "Geoffrey M. Clemm" <geoffrey.clemm@rational.com> To: ietf-dav-versioning@w3.org Subject: Re: Questions on activities From: jamsden@us.ibm.com <geoff> The reason CM systems restrict the names of versioning metadata is because those restrictions are essential for an implementation that scales. In particular, you can't efficiently cache information that is out of your control (i.e. in a namespace you don't control). So versioning metadata names will need to be restricted in order to provide CM functionality for the number of resources found on today's web sites. </geoff> <jra> Perhaps I'm missing something, but I don't see this. I agree that CM systems need to make all kinds of restrictions in order to manage the integrity of their repositories, and provide efficient implementations through predictable caching. But I don't see what this has to do with a WebDAV server that interfaces to these CM systems. I think the server mappings to the CM system allow the CM system to maintain its restrictions while the additional flexibility is implemented only in the WebDAV server. The majority of web servers (such as Apache and IIS) only handle a few top level name mappings, and hand the rest of the processing off to the underlying repository. So it is reasonable to associate some collection with a class of metadata, and map the URL of that collection to the appropriate underlying repository, but this does not allow you to make arbitrary associations between URL's and different kinds of metadata potentially from different repositories. So for example, the CM system can do all the caching it wants, and restrict versioning metadata as necessary to make it efficient. Its up to the WebDAV server implementation on that CM system to manage its bindings to the cached and restriced resources, including any additional caching and restrictions the WebDAV server may wish to impose on its behalf. Its using WebDAV as an associative object between the many-to-many association betwen clients and CM systems that enables this flexibility. While we are waiting for such WebDAV servers to be written, I'd like to make it possible to have implementations that are significantly simpler, and assume all but the top level name mappings are being maintained by the underlying repository. So I don't think these CM restrictions are invalid, I just don't think the necessarily need to be exposed in the WebDAV protocol. Make sense? </jra> Another reason to allow repositories to do most of the name mapping is that many users want to use several protocols to access a repository, and don't want to have to remember (and maintain) several namespaces to access data in the same repository. Cheers, Geoff