Next message: Geoffrey M. Clemm: "workspaces and configurations"
Date: Mon, 13 Mar 2000 23:15:14 -0500 (EST)
Message-Id: <200003140415.XAA24586@tantalum.atria.com>
From: "Geoffrey M. Clemm" <geoffrey.clemm@rational.com>
To: ietf-dav-versioning@w3.org
Subject: Notes from: Versioning TeleConf Agenda, 3/13/00 (Monday) 2-3pmEST
Attending:
Henry Harbury (Merant)
Jim Amsden (IBM)
Tim Ellison (OTI)
Geoff Clemm (Rational) (note-taker)
First Jim Amsden checked on who will be able to attend the Adelaide meeting.
Of those attending only Jim will be able to make it. Currently, Jim only
has one working group member other than himself attending, so please email
Jim if you can make it (the meeting will be held, even if only Jim and Eric
are there!).
The discussion then moved to the DAV:revision-selection-rule and locking.
Geoff pointed out that he has found no solution to the problem of
guaranteeing the integrity of locks other than the method posted earlier
to the newsgroup of "freezing" version selection for locked resources.
(As a reminder, the problem is that any change to versioning metadata such
as moving a label could result in the violation of a lock in some workspace
that uses that label in its revision selection rule. But it is not
feasible to locate all workspaces and evaluate all appropriate revision
selection rules to determine whether a lock will be violated by a particular
update to a piece of metadata).
Since revision selection is already rather complicated, Geoff is concerned
that having this freezing behavior in the presence of locks pushes the
complexity of the protocol beyond what is reasonable to expect servers to
implement or clients to understand.
Jim pointed out that it is not just a locking issue, but also
an efficiency issue, since a client that wanted to cache the version
selection computation would have a similar problem in decided whether
its revision selection cache is valid or not.
Geoff then proposed an alternative model of workspace revision selection,
where there is no DAV:revision-selection rule, but instead two new methods
that can be applied to workspaces: UPDATE and MERGE. These methods
are applied to a workspace, and their body indicates what revisions
should be selected by the workspace (UPDATE) or what revisions should
be merged into a workspace (MERGE). These two methods achieve (in a
static way) the effect of the DAV:or and DAV:merge operators in the
DAV:revision-selection-rule.
The benefit of this approach is that a workspace is only changed as
a result of an UPDATE, MERGE, CHECKOUT, PUT, etc applied directly to
a workspace, which can then be efficiently cached and checked for possible
lock violations.
Geoff further noted that the "set-default-revision" operation is then
just subsumed by the UPDATE method.
Jim indicated that he thought this was a simplification (and thus a good
thing), but regretted the loss of being able to have a declarative
description of "what was in the workspace".
Geoff agreed, but pointed out that this declarative description was
at the heart of the locking/efficiency problem.
After some discussion, the group agreed that the proposal merited
further study, and Geoff volunteered to write it up for the working
group. Everyone is encouraged to think hard about any alternative
approaches that might be used to address the locking/efficiency problem.
Cheers,
Geoff