Re: checkout/checkin/uncheckout vs. lock/unlock
Chris Kaler (ckaler@microsoft.com)
Tue, 1 Dec 1998 10:37:33 -0800
Message-ID: <4FD6422BE942D111908D00805F3158DF0A75794D@RED-MSG-52>
From: Chris Kaler <ckaler@microsoft.com>
To: "'David G. Durand'" <dgd@cs.bu.edu>, ietf-dav-versioning@w3.org
Cc: ietf-dav-versioning@w3.org
Date: Tue, 1 Dec 1998 10:37:33 -0800
Subject: RE: checkout/checkin/uncheckout vs. lock/unlock
And my grandfather's model T had a crank to start :-) just kidding....
You are right that CVS doesn't require it, but many systems do tie the two
together, so I believe we must have a way to do it. I also think that this
is a primary case. I'll take your point about CVS and say there are two
primary cases: (1) no lock, (2) lock. For primary cases I would prefer to
limit the round-trips required to the server. As well, many systems provide
a way to discover the current checkouts even if CVS doesn't. So here is the
point. You may want to take a lock, you may want to discover the checkouts,
you may want to search on the active checkouts. We have a mechanism in DAV
that supports these operations, LOCK. I understand that if you don't want
to lock the resource it may seem odd to use LOCK to checkout, but this does
seem cleaner than having to make two requests and define new discovery and
searching semantics/operations.
Chris
-----Original Message-----
From: David G. Durand [mailto:dgd@cs.bu.edu]
Sent: Tuesday, December 01, 1998 5:02 AM
To: ietf-dav-versioning@w3.org
Cc: ietf-dav-versioning@w3.org
Subject: Re: checkout/checkin/uncheckout vs.
lock/unlock
At 6:20 AM -0400 12/1/98, Ben Laurie wrote:
>Chris Kaler wrote:
>>
>> 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.
>
>CVS is widely used for collaboration, and in the standard
mode of
>operation no locks are taken out and there is no way to
know who else
>has anything checked out. In fact, to "release" a version
under CVS you
>can just do rm -r...
I was going to say "my point exactly" but in fact the CVS
model is _more_
radical -- there's really no need for even a checkout
operation in that
model. Checkout is sufficient to provide notification, etc.
It's doubtful
that all of the notification and status mechanisms for locks
will be
exactly the same as those for collaboration. Even if the
mechanisms are the
same, if the operations are combined, you can't implement
separate policies
for the two situations. And that's clearly more suspect.
To me the similarities in notification and discovery can't
hide the basic
disconnect with repect to core functionality: a checkout
simply need not
lock anything (depending on server policy). Given that, it's
not
appropriate to call it a lock, or to overload the locking
methods.
-- 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
\__________________________