DeltaV Teleconference
March 13, 2000

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.

*** End of teleconference ***