W3C home > Mailing lists > Public > w3c-dist-auth@w3.org > January to March 1997

RE: Last call: range locking

From: Gregory J. Woodhouse <gjw@wnetc.com>
Date: Mon, 3 Mar 1997 21:06:46 -0800 (PST)
To: Yaron Goland <yarong@microsoft.com>
cc: "'Jim Whitehead'" <ejw@ics.uci.edu>, w3c-dist-auth@w3.org
Message-ID: <Pine.SGI.3.95.970303204524.27715B-100000@shellx.best.com>
On Mon, 3 Mar 1997, Yaron Goland wrote:

> Pro Range Locking - Steve Carter, Yaron Y. Goland, and Gregory J.
> Woodhouse, 
> Anti Range Locking - Larry Masinter, Mark Day, and Fabio Vitali

Yes, I would like to see range locking, but I have one big question that I
think needs to be resolved first. If it were possible to lock a byte range,
any modifications to the resource that fall outside the byte ranges would
still invalidate all cache entries xorreponding to the resource. This being
the case, I don't know what is to be gained by locking a byte range versus
locking the resource.

Larry's point that byte ranges really apply to entities and not resources
is a good one, too. This means we would have to think carefully about

What would actually work for the application I have in mind (and maybe
would even be preferable) would to allow partial locks (terminology?) of a
resource represented by a multipart entity such that lock would apply to a
component subpart. I'm obviously in a real terminological tangle here
because the entity is multipart but it doesn't make sense to say the
resource is multipart. In any case, assuming this makes sense and it can be
made to work, then it might be possible to cache component subparts of a
multipart entity (but would this be made to work with HTTP/1.1 as is?) then
there would be something to be gained from a partial lock. 
gjw@wnetc.com    /    http://www.wnetc.com/home.html
If you're going to reinvent the wheel, at least try to come
up with a better one.
Received on Tuesday, 4 March 1997 00:13:31 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 20:01:10 UTC