- 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
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 definitions. 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