Next message: Tim Ellison OTT: "RE: Target-Selector"
From: jamsden@us.ibm.com
To: ietf-dav-versioning@w3.org
Message-ID: <85256854.00797594.00@d54mta03.raleigh.ibm.com>
Date: Mon, 27 Dec 1999 17:06:56 -0500
Subject: Re: Exclusive Locking ... per lock type?
Unfortunately I think the answer to this depends on the meaning of other
potential locktypes and their interaction with other locktypes. So it
probably can't be specified. For example consider a read lock. If Joe has
resource index.html exclusive write locked, then no one else can PUT to the
resource. Anyone else can still read it though. Now Joe, or even someone
else, could come along and take out an exclusive read lock which would also
prevent anyone else from reading index.html, presumably to keep people from
being confused by broken links until Joe is done with his updates. It would
be pretty funky if Joe didn't take out this read lock though. Its pretty
hard to update things one can't read.
"Geoffrey M. Clemm" <geoffrey.clemm@rational.com>@w3.org on 12/27/99
04:39:17 PM
Sent by: w3c-dist-auth-request@w3.org
To: w3c-dist-auth@w3.org
cc:
Subject: Exclusive Locking ... per lock type?
Did section 8.10.6 of 2518 meant to say that an exclusive
lock will fail if there already is a lock *of that locktype* on that
resource, or if there is *any* exclusive lock there?
I can see arguments for both directions, and implementors probably haven't
thought that much about it since everybody is just doing write locks,
but I assume the authors had one or the other in mind?
Cheers,
Geoff