- From: Yaron Goland <yarong@microsoft.com>
- Date: Wed, 26 Feb 1997 21:10:53 -0800
- To: "'Steve Carter'" <SRCarter@GW.NOVELL.COM>, "'masinter@parc.xerox.com'" <masinter@parc.xerox.com>, "'w3c-dist-auth@w3.org'" <w3c-dist-auth@w3.org>
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