Re: range locking not used in GroupWise

I realize that many in this group are focused exclusively on Internet issues.
My focus is on back-end issues especially where it deals with legacy systems
exposing their functionality via WebDAV. I agree with what you pointed out
when it pertains to Internet documents, however, the argument does not
hold water when exposing a non-web based document repository where
data structures other than file systems are used to organize documents
and provide access. If we are only concerned with Internet resource documents
then we can dump a whole truck load of concerns, we can also expect that WebDAV
will not be the mechanism to expose the multitudes of documents held in
back-end document repositories.

-src

>>> Larry Masinter <masinter@parc.xerox.com> 02/25/97 06:23AM >>>
Steve Carter wrote:
> 
> No, I don't feel that expediency is the issue. Clustering (granularization) is a common
> method of handing shared things. In many operating systems the easiest way
> to do this is to use byte range locking. It is a quick way of creating a shared
> semaphore.

The web is an unusual operating system, though. (The Internet is an
unusual computer.)
In Webdav, we've been pursuing using links and site maps to do
clustering, and
it seems that so far we can handle these issues by having separate
resources
with a relationship between them, and having the lock operation work on
the
separate URLs.

It might be that in one implementation
"http://server.dom/resource/bytes=1-12"
is a byte range of "http://server.dom/resource", but we don't need to
standardize
on that, only the relationship between them. 

Clearly we have to address the container/contained relationships, that
locking a chapter has some effect on the lock state of the entire book.
If we can handle the relationship at the larger granularity, we probably
should use the same mechanism for dealing with locks even with a finer
grain.

Larry
                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                               !
                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                               !

Received on Tuesday, 25 February 1997 10:39:48 UTC