Date: Wed, 12 Apr 2000 08:58:29 -0400 (EDT) Message-Id: <200004121258.IAA12337@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 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. =A0So 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. </geoff> <jra> This won't be true of WebDAV servers that support BIND. They will have to have much more support for mappings. </jra> The chances that a WebDAV server will support any BIND functionality not already provided by the underlying repository is vanishingly small. The semantics of BIND requires that a binding not be broken because of some operation on some other binding to that resource. In particular, this means that any underlying implementation artifacts that support that resource cannot be destroyed while there remains a binding to that resource. Since most/all repositories of interest provide access by multiple protocols to the underlying data, this requires intimate knowledge by the repository of all bindings, which would not be the case for any attempt to layer binding functionality above the repository in the web server. It also would require that the repository expose a "unique-id" that the web server could use to identify the implementation artifacts to the web server, which for many repositories of interest (e.g. file systems) is not made externally available. 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. <jra> These are not repository semantics, but WebDAV binding and versioning semantics. The implementation shouldn't be in the repository managers as this would require repository managers to know and implement WebDAV semantics, something they shouldn't be expected to do. </jra> Because of the difficulty and complexity of engineering scalable implementations, the repository managers are exactly where the WebDAV semantics will be implemented. In the case of BIND, the reasons why repositories implement only a subset (or none) of the bind semantics is that a scalable general bind implementation is either very hard or impossible, depending on what else the repository is trying to do. Cheers, Geoff