Next message: jamsden@us.ibm.com: "RE: Questions on activities"
Message-ID: <65B141FB11CCD211825700A0C9D609BC01879A80@chef.lex.rational.com>
From: "Vasta, John" <jvasta@Rational.Com>
To: ietf-dav-versioning@w3.org
Date: Tue, 11 Apr 2000 09:09:50 -0400
Subject: RE: Questions on activities
Another reason to not require web servers to maintain mappings between URLs
and CM resources is to allow for scaling up access by providing more web
servers as access points for the same CM repositories. If the web server was
maintaining mappings, then you would have to worry about replicating and
synchronizing those mappings across multiple servers. There are also CM
systems which allow for replication of their repositories; any external
mappings would have to be separately replicated as well. The protocol will
be much more successful if it accomodates the architectures of existing CM
systems, and allows for relatively straightforward and efficient
implementations.
John Vasta
> -----Original Message-----
> From: Geoffrey M. Clemm [mailto:geoffrey.clemm@Rational.Com]
> Sent: Monday, April 10, 2000 11:25 PM
> 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
>