Re: Locking in a versioning server
jamsden@us.ibm.com
Thu, 4 Nov 1999 21:13:47 -0500
From: jamsden@us.ibm.com
To: ietf-dav-versioning@w3.org
Message-ID: <85256820.000C3CF8.00@d54mta03.raleigh.ibm.com>
Date: Thu, 4 Nov 1999 21:13:47 -0500
Subject: Re: Locking in a versioning server
<geoff>
Good point. I'm still against this lock semantics for versioned resources
though (:-).
</geoff>
<jra>
(Reference to locking a versioned resource implies preventing checkouts on
any revision except by the lock owner(s)): Why? Looks useful to me, doesn't
cause any harm, and is consistent with the notion of locking and control of
updates. Yes it significantly limits concurrent development to the
(potentially shared) lock owner(s), but in this case, that's the point. If
that's not what you want, then don't lock the versioned resource.
</jra>
<geoff>
Shared locks implicitly involve some kind of ACL on who can take out
the shared lock. But if you have an underlying ACL system, what do
shared locks give you that you can't just get from the underlying
ACL system?
</geoff>
<jra>
Locks are different than ACLs in that locks are transient and register an
intent to modify. ACLs play a different role and shouldn't be overloaded
with change management semantics.
</jra>