Next message: jamsden@us.ibm.com: "Re: WebDAV Versioning Scenarios"
Date: Tue, 28 Mar 2000 23:54:39 -0500 (EST)
Message-Id: <200003290454.XAA21252@tantalum.atria.com>
From: "Geoffrey M. Clemm" <geoffrey.clemm@rational.com>
To: ietf-dav-versioning@w3.org
Subject: Re: WebDAV Versioning Scenarios
From: jamsden@us.ibm.com
I think there is a real simple way to describe the new workspace
semantics that is fully consistent and conpatible with existing
semantics. It goes something like this:
A workspace describes dynamic or variable a set of revisions. It
represents a place where a client or group of clients does work by
making changes to resources directed at some desired end result. A
workspace has a revision selection rule that describes the revisions
that were selected by the workspace creator. A workspace MAY
dynamically update its contents based on changes in the revision
selection rule, or changes to resources managed by the server, e.g.,
creation of new versioned resources, labeling revisions, checking in
working resources in an activity, updating a configuration,
etc.
The key problem here is the "MAY". Basically, any MAY is a headache
for a client writer, since it means the client writer can't count on
that aspect of server behavior. I believe advanced versioning is too
complicated to introduce a "MAY" in something as central as revision
selection.
I do know of one high-end CM company that supports both dynamic
and static workspaces (I work for it, in fact :-), so
I can personally vouch for how hard it is to actually
implement dynamic workspaces that support non-trivial version
selection rules, and how much work it is to write clients that allow
a user to sensibly deal with both dynamic and static workspaces.
I believe the practical result will be some clients that support
only static workspaces, some that support only dynamic, and most
that won't support workspaces at all since they can't count on
consistent semantics from servers.
So as cool as dynamic revision selection is, I believe we should
excercise self-restraint and commit to static revision selection
for the first version of the versioning protocol.
Once that is widely implemented, and implementors are just dying
to do something more challenging (:-), I'd be happy to consider
adding in dynamic revision selection.
Cheers,
Geoff