Range Locking and Caching

Caching is not a major issue vis a vie most of DAV's functionality,
ESPECIALLY range locking. The reason being that caching is only useful
when a resource's entities remain stable for a relatively long period of
time. The act of editing a document, which is the end to which we wish
to put range locks, means that the entities associated with a resource
are not stable and thus are not suitable for caching.

This point having been made, my own proposal for range locking involves
having a URL assigned to a byte range and then performing normal locking
operations on that URL. So any server suicidal enough to send out an
entity corresponding to a URL which represents a locked byte range
without a cache control - no-cache is free to do so.

		Yaron

>-----Original Message-----
>From:	Gregory J. Woodhouse [SMTP:gjw@wnetc.com]
>Sent:	Monday, March 03, 1997 9:07 PM
>To:	Yaron Goland
>Cc:	'Jim Whitehead'; w3c-dist-auth@w3.org
>Subject:	RE: Last call: range locking
>
>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 13:50:41 UTC