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