W3C home > Mailing lists > Public > w3c-dist-auth@w3.org > January to March 1997

Re: Range locking

From: Steve Carter <SRCarter@novell.com>
Date: Thu, 20 Feb 1997 15:48:35 -0700
Message-Id: <s30c75ad.057@novell.com>
To: Mark_Day/CAM/Lotus@lotus.com, w3c-dist-auth@w3.org
So, Mark, you vote that we abandon all legacy clients and design the *pure* protocol for WebDAV?


>>> <Mark_Day/CAM/Lotus@lotus.com> 02/20/97 11:52AM >>>

Explaining why range locking was required, Jim <ejw@ics.uci.edu> wrote:

'Discussion on this issue at Irvine was mostly concerning the development
of "yet another range identification scheme," rather than "we should remove
range locking from the requirements."  In fact, this has been a requirement
since last October, and has passed several reviews.  In a nutshell, the
rationale for this requirement is that certain application programs
(typically word processors) which perform range management within a file
(typically using a table with fixed width entries, located at the beginning
of the file, each entry containing range information), would find
sub-resource locking to be very useful.'

Jim's memory of this discussion differs from mine. I remember the flavor
being much more at the level of saying that range locking was incompatible
with one of the stated design principles (that resources are the lockable
entities). Further,  range locking seemed to be a hack to accommodate
legacy clients, rather than being part of a coherent design for how
distributed authoring and versioning works on the Internet. I had the
impression in Irvine that there was rough consensus that the group's
purpose was to devise a good design for the Internet going forward, not
just a web veneer for existing servers and clients.

BTW, I find it dubious that "having passed several reviews" would somehow
make a requirement more correct or virtuous. I thought the whole point of
having further meetings and reviews was to discover problems not previously



Received on Friday, 21 February 1997 03:59:39 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 20:01:10 UTC