RE: range locking not used in GroupWise
Goal: To provide locking for defined subsections of a document
Problem: DAV only supports locking on URLs, as URLs are given to a
resource as a whole, DAV can not currently handle a partial lock
Solution: Give subsections URLs.
Example: Byte Ranges - A client searches for the attribute
"xssdfsyhw30rwfwofjslfihleihfsfe" which is a token meaning "I give you
permission to mangle the URL for this resource to point to a byte range
in a defined way, specifically, you may add a "#" followed by a number,
followed by a dash, followed by another number". The client then sends
http://foo/bar#12-23 in a lock request. The result is that bytes 12 to
23 are locked. Obviously the example doesn't provide all the semantic
requirements but it is just a taste of the underlying mechanism.
Problem: Mangling Overload. It is very nice and good to mangle a URL
w/permission from the server, but at some point the various mangling
mechanisms are going to run into each other.
Potential Solution: A byte range method called ByteHead =). A range
header is included to specify the byte range, although it can be used to
specify any arbitrary range such as chapter or page. The request-URI is
the request-URI of the resource. The response contains a
content-location header which is the URL pointing to the relevant range.
The rest of the response contains the same thing as a HEAD request done
on the URL contained in content-location.
Problem: Two round trips for every single lock request.
Solution: A convenience method which combines ByteHead with Lock, we can
call it LocksByte.
>From: Steve Carter [SMTP:SRCarter@GW.NOVELL.COM]
>Sent: Tuesday, February 25, 1997 4:40 PM
>To: firstname.lastname@example.org; email@example.com
>Subject: Re: range locking not used in GroupWise
>You are right, the protocol does not need to deal with the range lock.
>If needed it can be performed at the resource level. If a DMS manages
>documents via a database then the resource name becomes the
>access name for the document.
>I believe we are no longer at cross purposes.
>>>> Larry Masinter <firstname.lastname@example.org> 02/25/97 07:51AM >>>
>You keep on talking about function, and I'm talking about protocol.
>The issue isn't whether the function needs to get exposed, the
>issue is whether the protocol needs to be aware of it. I don't
>see any good reason why the protocol needs to get more complicated
>to deal with "byte range locking" when "resource locking" covers
>it, because a "byte range" can be a "resource".
>Is there really a disagreement, or are we just talking at cross