RE: Deleting versions

   From: Lisa Dusseault [mailto:lisa@xythos.com]

   Are DeltaV servers then not required to support locking at all?

Correct.

   Lock-null comes along with lock.

Not from Microsoft (:-).  You get locking, but not lock-null's
or depth locking with their IIS WebDAV server.  But I agree that
the protocol states that lock-null comes along with lock
(at least, for the current rev of the DAV protocol :-).

   I can (barely) beleive that a server might implement
   DeltaV but not support locking.

Last I heard, Greg had no intentions of implementing locking with
his DeltaV server.  We (i.e. Rational) are
likely to initially only support the limited
amount of locking expected by a Microsoft client (i.e. single
resource locking, but no lock-nulls or depth locks).

   In fact, you acknowledge in section 14 that
   lock-null may be implemented:

   "Non-version-controlled bindings are not under version control, and
   therefore can be added or deleted without checking out the
   version-controlled collection.  This feature is essential for the
   support of lock null resources, since a lock null resource is a
   temporary internal member of a collection that should only exist
   for the duration of the lock, and should not be captured in the
   version history of that collection."

Yes, it is essential that the DeltaV protocol be compatible with
the locking protocol (if it isn't, please let me know!).  But that
doesn't mean it should depend on or be otherwise concerned with it.
To the contrary, ensuring that the versioning protocol is orthogonal
to the locking protocol allows the versioning and locking protocols
to evolve independently.  Any explicit statement in the versioning
protocol about the locking protocol risks a conflict with a
statement made in later versions of the locking protocol.

   You're doing what Greg (justly) accused you of and leaving things to be
   inferred, or out of the spec entirely.  If DeltaV says nothing, then
   implementors and servers that do locking and deltaV will be left without
   guidance, on an issue over which the experts (heh) have argued.  Their
   implementations will differ.

If an implementor wants to find out about locking, they should go to
the (current version of) the locking protocol.  We don't want to rev
the versioning protocol every time the locking protocol changes.  So
if there is some subtle locking/versioning interaction, then I agree
that should be identified in the versioning protocol (in particular,
the interaction between lock null resources and versioned collections
is such a case, and therefore is identified).

So let's get some feedback from the working group: 
Who thinks that the ability to apply MKWORKSPACE or MKACTIVITY
is a versioning/locking interaction that merits explicit
mention in the versioning protocol?  (I think we can take it
as given that Lisa thinks "yes" and I think "no").

As with the DAV:resourcetype thread, I've made all the points
I wanted to make, so I'll leave it up to working group consensus.

Cheers,
Geoff

Received on Wednesday, 6 June 2001 12:43:02 UTC