- From: Yaron Goland <yarong@microsoft.com>
- Date: Tue, 4 Mar 1997 10:49:47 -0800
- To: "'Gregory J. Woodhouse'" <gjw@wnetc.com>
- Cc: "'Jim Whitehead'" <ejw@ics.uci.edu>, "'w3c-dist-auth@w3.org'" <w3c-dist-auth@w3.org>
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