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.

			Yaron




>-----Original Message-----
>From:	Steve Carter [SMTP:SRCarter@GW.NOVELL.COM]
>Sent:	Tuesday, February 25, 1997 4:40 PM
>To:	masinter@parc.xerox.com; w3c-dist-auth@w3.org
>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.
>
>-src
>
>
>>>> Larry Masinter <masinter@parc.xerox.com> 02/25/97 07:51AM >>>
>Steve,
>
>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
>purposes?
>
>Larry
>

Received on Thursday, 27 February 1997 00:11:02 UTC