Re: Questions on activities

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

  • Next message: Geoffrey M. Clemm: "Re: Unversioned members of versioned collections"

    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