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

Chris Kaler (ckaler@microsoft.com)
Mon, 30 Nov 1998 15:00:25 -0800 

Message-ID: <4FD6422BE942D111908D00805F3158DF0A75793F@RED-MSG-52>
From: Chris Kaler <ckaler@microsoft.com>
To: Chris Kaler <ckaler@microsoft.com>,
Date: Mon, 30 Nov 1998 15:00:25 -0800
Subject: RE: checkout/checkin/uncheckout vs. lock/unlock

Couple more thoughts...

Using LOCK also allows us to leverage the lock discovery mechanism as well
as any DASL searching semnatics.

Chris

		-----Original Message-----
		From:	Chris Kaler [mailto:ckaler@microsoft.com]
		Sent:	Monday, November 30, 1998 11:40 AM
		To:	'Geoffrey M. Clemm'; ietf-dav-versioning@w3.org
		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.