Re: Questions on activities

From: Geoffrey M. Clemm (geoffrey.clemm@rational.com)
Date: Mon, Apr 10 2000

  • Next message: Geoffrey M. Clemm: "Re: Stable URLs"

    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