Re: checkout/checkin/uncheckout vs. lock/unlock

David G. Durand (dgd@cs.bu.edu)
Mon, 30 Nov 1998 21:59:39 -0400 

Message-Id: <v04011701b288fb4126e3@[24.0.249.126]>
In-Reply-To: <4FD6422BE942D111908D00805F3158DF0A757935@RED-MSG-52>
Date: Mon, 30 Nov 1998 21:59:39 -0400
To: ietf-dav-versioning@w3.org
From: "David G. Durand" <dgd@cs.bu.edu>
Subject: RE: checkout/checkin/uncheckout vs. lock/unlock

>I'd like to hear who these people are.  Most people I talk to either do
>implicit versioning (don't want to be bothered by it, just make it happen)
>or use exclusive versioning (which requires locking).  So I find this
>requirement confusing.  Not to mean its invalid, I've just never heard it
>before.

I've certainly mentioned it almost every time I open my mouth. It's one of
my little obsessions.

If you're supporting tight collaboration, you may prefer to allow
(temporary) divergence in document state in order to achieve maximal
progress (automatic forking is one way to avoid locking). Similarly, if you
are relying on merge tools (like the CVS model for software version
control) you may prefer to create a conflict that can be resolved later,
rather than block the human.

My database teacher always used to point out that some actions (like making
a report to a terminal, or starting a user interaction) inherently
commitcommit a transaction because you "can't abort the user." Similarly in
editing, you may not want to lock out a user, but that doesn't mean that
you just want to lose information either.

Separating checkout (reservation, as we called it in the requirements
document) from locking makes this distinction clear. It also separates the
"transaction management" function of a checkout (maintaining whatever state
the server may need to maintain) from the locking function: (which enforces
access conditions on a resource).

One thing we _could have_ (I'm not advocating this, but some might) is a
response that would let a server tell a client that a lock has been
assigned as a result of the checkout operation. Servers that enforce
locking all the time would then be able to inform clients of the needed
lock ID. This makes the protocol more complex, but reduces the round trips
for a lock/checkout pair.

Those of you who are building servers that enforce this kind of locking
probably know more than I do about whether that's a needed tradeoff.

  -- David
_________________________________________
David Durand              dgd@cs.bu.edu  \  david@dynamicDiagrams.com
Boston University Computer Science        \  Sr. Analyst
http://www.cs.bu.edu/students/grads/dgd/   \  Dynamic Diagrams
--------------------------------------------\  http://www.dynamicDiagrams.com/
MAPA: mapping for the WWW                    \__________________________