Next message: Sankar Virdhagriswaran: "Re: WebDAV Versioning Scenarios"
From: jamsden@us.ibm.com
To: ietf-dav-versioning@w3.org
Message-ID: <852568B1.002F99AF.00@d54mta03.raleigh.ibm.com>
Date: Wed, 29 Mar 2000 03:39:52 -0500
Subject: Re: WebDAV Versioning Scenarios
I agree with Geoff. I only want to make sure we don't design workspaces is
such a way that dynamic workspace would be ruled out, or significantly
different than static workspaces. So that's why I would like to keep the
revision selection rule in the workspace, even if the revisions are
selected with an explicit REFRESH method. Dynamic workspace would be
exactly the same except the REFRESH wouldn't be required an would be
ignored.
|------------------------+------------------------>
| | "Geoffrey M. Clemm" |
| | <geoffrey.clemm@ratio|
| | nal.com> |
| | Sent by: |
| | ietf-dav-versioning-r|
| | equest@w3.org |
| | |
| | 03/28/2000 11:54 PM |
| | |
|------------------------+------------------------>
>------------------------|
| |
| To: |
| ietf-dav-versioning@w|
| 3.org |
| cc: |
| 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