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

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

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

Rather than scatter comments, I'll comment here...

I think that locking and the working resource are both important.  As I go
around and ask people what checkout means to them, I hear both.  The problem
we discovered at the last meeting is that CHECKOUT and LOCK have overlap and
you either have to perform an extra round-trip on the most common operation,
have one method effect the other, or merge the methods.  Given that LOCK
exists and has many of the semantics we desire: discovery, cancel, supports
multiple types of locks, and eventually searchable from DASL, it seems like
a win to keep the complexity down and just merge the two.  It also makes the
protocol changes from non-versioning to versioning a small delta that builds
on the existing protocol.  This was my reasoning.

Remember that revisions are partially mutable.  There are mutable properties
and several folks have indicated that most of their properties are mutable.
Actually, I think the working resource is only interesting when you are
doing shared updates.

Chris

		-----Original Message-----
		From:	David G. Durand [mailto:dgd@cs.bu.edu]
		Sent:	Monday, November 30, 1998 6:36 PM
		To:	Chris Kaler; 'Geoffrey M. Clemm';
ietf-dav-versioning@w3.org
		Subject:	RE: checkout/checkin/uncheckout vs.
lock/unlock

		At 3:39 PM -0400 11/30/98, Chris Kaler wrote:
		>My idea was that if we make them the same method, you
remove much of the
		>confusion.  A checkout is, in many ways, a lock.  You
"checkout" either
		>shared or exclusive.  That is the same as a lock.  The only
difference is
		>that you have a working resource.

		Well, the working resource is the important thing. Locking
(in the sense of
		blocking some operations) is purely optional depending on a
server's
		desired policy. This seems like two things glommed together
into one method
		to me.

		>		- What if you want to leave the working
resource available
		>for anyone
		>		to modify?  In what sense have you created a
lock?
		>
		>You make it shared and everything is fine
		>
		>		- When you checkin a resource, you have now
made an
		>immutable revision.
		>		In what sense have you "unlocked" anything?
		>
		>I argue that a checkout is an implicit lock against the
resource and by
		>checking in, you have removed that lock.

		Since the resource was not modifiable, it's a funny kind of
lock. If the
		access is non-exclusive (anyone else can do a checkout as
well), it's not
		even a lock in the sense that it blocks other checkout
operations. In fact,
		in that case, it's not very lock-like at all, since no
operation is blocked
		by it.

		You didn't actually answer the objections either, but just
repeated your
		assertion. Maybe my verbose statement of why it's not a lock
will give you
		a better handle for arguing your point.

		So I think that the notion is rather confusing. Servers that
don't offer
		locking (are then required to supply "non-exclusive locks",
and track their
		IDs, when in fact they need no such objects or functions...
While I approve
		of complexity in the server more than complexity in the
client, it seems to
		me that this makes life harder for clients as well...

		>		- Converely, when you "uncheckout" a working
resource, you
		>delete it.
		>		In what sense have you "locked" anything?
		>
		>This is another reason why I like the LOCK method.  In many
systems,
		>explicit locking is used.  PUTs with require the lock-id to
be specified.
		>By tieing the two together, clients don't need to worry (or
think) abou the
		>"working resource".  They do their PUT to the versioned
resource and specify
		>the checkout lock.  The server validates the lock and
updates the working
		>resource.  I actually think this is much easier for the
client than having
		>to track the versioned resource, the working resource, and
the lock-id.
		>Less information, consistent protocol.

		You seem to making a round-trips argument. In my other
message, I suggest
		that this could be optimized without merging the two
methods. It always
		seemed reasonable to me that a checkout _might_ create a
lock (since that's
		the way many systems work). Requiring that a lock be created
seems a
		different kettle of fish (since other systems don't have the
notion of
		locking).

		>		- When you "checkout" a versioned resource,
you create a new
		>(working)
		>		resource.  A "lock" is not something you
expect to create a
		>new resource.
		>
		>But many (most) checkouts result in the versioned resource
being locked in
		>some way.  So this approach lessens the round-trips and the
information the
		>client must track and keeps the protocol almost exactly the
same as
		>non-versioning.

		This merger would be a lot more appealing if the semantics
of "checkout
		locks" really matched the semantics of other locks: since a
"non-exclusive
		checkout lock" is actually equivalent to no locking at all,
this strikes me
		as more confusing than useful, especially since the extra
round trip can be
		eliminated _without_ merging the concepts of checkout and
lock for
		everybody.

		  -- 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
\__________________________