Re: range locking not used in GroupWise

This is interesting. Caching in HTTP works precisely because it implememnts
the immutable file model of a distributed file system...or at least that's
the way I tend to think about it. Your point that entities are immutable
and reources are not is, of course, correct. The difference is that I think
of the combination of a resource and a validator for that resource (think
of it as a version, something like a version number of an OpenVMS file) as
the immutable object.

On Wed, 26 Feb 1997, Larry Masinter wrote:

> Byte ranges (in HTTP range retrieval) don't apply to resources.
> They apply to entities. An entity is the data stream that
> you get when you perform a GET operation. Servers are free
> to ignore byte range requests and deliver the entire
> entity rather than the indicated range.
>

I'm not sure about this one. Certainly, if a resource is modified, a byte
range may become an inaccurate representation of that resource (or, perhaps
I should say valid entity), and in this sense I agree with you. But byte
range requests are made against resources and not entities. It seems that
the real point is that the link between a byte range and a reource is a
transient thing, whereas the link between a byte range and an entity is
permanent.
 
> Resources don't have "byte ranges". Entities are immutable.
> They don't change. Since they don't change, it doesn't make
> sense to lock one or even lock part of one.
> 

I'm not quite sold. As I indicated in an earlier message, it may be that a
byte range lock is not a useful concept, but it is still meaningful. For
the purposes of this post I will define a version of a reource to be a
resource together with a unique validator for that resource. With this
definition, it makes sense to require that new versions of a resource can
only be created subject to the constraint that the byte range 0-500 is the
same for both versions. (I know this use of version is not consistent with
WEBDAV terminology, but it saves a lot of words.) Surely, this is a
meaningful requirement.

Is it a useful concept? I don't know. The problem is that byte ranges need
to be independently cacheable or there is no advantage in locking a byte
range instead of locking the whole resource. The problem is that if
resource R is represented by a 1000 byte entity, and person A has already
obtained byte ranges B1 and B2 representing bytes 0-500 and 501-1000
respectively, and both are available in cache, then if that person wants to
GET the resource (not a byte range), then the corresponding entity E is the
union of B1 and B2, and so it should not be necessary to transer the whole
entity, a revalidation should be sufficient. But how can this be done? Even
if the byte ranges have their own validators e1 and and e2, there is no
relationship between the pair (e1,e2) and a validator e for R.

(Sorry for all the "symbol speak". I guess my background in mathematics is
catching up with me.)


[...]

---
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 Friday, 28 February 1997 02:05:29 UTC