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

Chris Kaler (ckaler@microsoft.com)
Mon, 30 Nov 1998 11:39:39 -0800


Message-ID: <4FD6422BE942D111908D00805F3158DF0A757934@RED-MSG-52>
From: Chris Kaler <ckaler@microsoft.com>
To: "'Geoffrey M. Clemm'" <gclemm@tantalum.atria.com>,
Date: Mon, 30 Nov 1998 11:39:39 -0800
Subject: RE: checkout/checkin/uncheckout vs. lock/unlock

What we agreed to was that we liked multiple methods instead of just one
:-).  However, we discovered that there was a conflict between checkout and
lock.  I was supposed to start an email thread about it, but got hung up.

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.

		- 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.

		- 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.

		- 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.

Chris


		-----Original Message-----
		From:	Geoffrey M. Clemm [mailto:gclemm@tantalum.atria.com]
		Sent:	Tuesday, November 03, 1998 10:30 AM
		To:	ietf-dav-versioning@w3.org
		Subject:	checkout/checkin/uncheckout vs. lock/unlock


		Why was the checkout/checkin/uncheckout functionality
assigned
		to the lock/unlock methods?  As I recall, in our last
meeting,
		we agreed (or at least, all of us but Chris agreed, and
Chris
		reluctantly accepted :-) that they each really needed to be
a
		separate method.

		There was a proposal to allow you to optionally "lock" a
working
		resource as part of the checkout command (which is fine with
me),
		but making the checkout command actually be a variant of the
"lock"
		makes no sense to me.

		- What if you want to leave the working resource available
for anyone
		to modify?  In what sense have you created a lock?

		- When you checkin a resource, you have now made an
immutable revision.
		In what sense have you "unlocked" anything?

		- Converely, when you "uncheckout" a working resource, you
delete it.
		In what sense have you "locked" anything?

		- When you "checkout" a versioned resource, you create a new
(working)
		resource.  A "lock" is not something you expect to create a
new resource.

		So I propose that we not overload lock/unlock, but that we
have 3 new
		methods: CHECKIN, CHECKOUT, UNCHECKOUT.

		Cheers,
		Geoff


		Note: my previous message to ietf-dav-versioning@w3.org
appears to
		have been distributed fine (or at least, it make it back to
me with
		no trouble.  So whatever problem Chris was having seems to
have either
		been fixed, or is a local problem at his home mailing site.