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

Chris Kaler (ckaler@microsoft.com)
Mon, 30 Nov 1998 20:47:16 -0800 

Message-ID: <4FD6422BE942D111908D00805F3158DF0A75794A@RED-MSG-52>
From: Chris Kaler <ckaler@microsoft.com>
To: "'David G. Durand'" <dgd@cs.bu.edu>, ietf-dav-versioning@w3.org
Date: Mon, 30 Nov 1998 20:47:16 -0800
Subject: RE: checkout/checkin/uncheckout vs. lock/unlock

There are several types of locks.  Shared, Advisory, and Exclusive.  I
cannot see why you would (in most cases) want to check out a resource
without taking one of these locks.  In a collaboration world, you want to
know who else is working on the document.  Locks provide an existing
mechanism to discover and manage this information.

Personally, I don't like the idea of method side-effects: "BTW this
operation also locked something."  

Hopefully we can continue this discussion on Wed.

Chris

		-----Original Message-----
		From:	David G. Durand [mailto:dgd@cs.bu.edu]
		Sent:	Monday, November 30, 1998 6:00 PM
		To:	ietf-dav-versioning@w3.org
		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
\__________________________