Next message: Tim Ellison/OTT/OTI: "Moving a label"
Date: Mon, 3 Jul 2000 12:33:39 -0400 (EDT)
Message-Id: <200007031633.MAA03397@tantalum.atria.com>
From: "Geoffrey M. Clemm" <geoffrey.clemm@rational.com>
To: ietf-dav-versioning@w3.org
Subject: Re: Branching, repositories, and activities
From: jamsden@us.ibm.com
But any WebDAV versioning server that uses RCS as its underlying repository
will have to do lots of things in the server implementation to do the
mapping. For example, properties, bindings, and locking will all have to be
implemented in the WebDAV server.
Most servers will not support bindings and many servers will not
support locking. Many servers will only support the live properties
required by the protocol, and a few additional properties that reflect
some additional semantics of the underlying implementation.
This is typical of any implementation of
WebDAV on a repository manager. The mapping of WebDAV semantics onto a
given repository manager may be thick or thin depending on how well the
semantics match.
The WebDAV protocol has been designed to reflect the wide variety of
semantics supported by existing (and future) repositories. A protocol
feature that requires a thick layer above common repositories is
unlikely to be widely implemented. It is easy to implement a "toy"
version of any feature, but an industrial strength version that scales
is a major undertaking, and not one likely to be widely attempted.
For RCS, a WebDAV server implementation might use a
relational database to store WebDAV properties and locks. It could also use
the database to store versioning meta-data and resources. This is similar
to how mod_dav and DAV4J map WebDAV onto the file system.
Versioning is much harder to implement than properties or locks (although
an implementation of properties and locks that scales can in fact be a
challenge). I believe that what is commonly implemented today in terms
of versioning is a good guide to what is feasible and desireable.
So I don't think that just because some repository manager doesn't directly
map to WebDAV versioning semantics implies that we need to complicate the
protocol with special cases supporting that particular repository's model.
Given a choice between two alternatives (e.g. a MKACTIVITY method
and a "new-activity" switch to the CHECKOUT method), the alternative that
matches a wider variety of implementations is a strong consideration.
Instead we should concentrate on a simple versioning model that supports
the desired scenarios, and make sure it is reasonably possible to map the
model on many existing repository managers. This doesn't mean the mapping
has to be direct though.
I believe the degree to which the protocol directly maps to existing
repositories will be directly correlated to the degree to which the
protocol is implemented and adopted.
Cheers,
Geoff