Re: Range locking

>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
>exposed.

Well, there's a tension here.  Much of the benefit from creating a
requirements document derives from creating consensus on what features
should and should not be in the final protocol specification.  Based on
this consensus, we can determine whether our specification meets the
requirements, and we can discard features which go beyond the requirements.
Having worked hard to achieve consensus on the original requirements
document, I do feel justified in pushing back when features which were
originally agreed upon now suddenly are in question.

However, this is definitely at odds with the notion (that I also agree
with) that any bad requirement or feature should be removed, no matter how
much agreement there existed upon it.  Plus, we're also now in a period of
reexamination of the original requirements documents.  That's why in my
explanation I also gave a thumbnail rationale for the requirement, because
I don't feel that precedent alone is sufficient.

I do disagree with the characterization of range locking as a hack.
Another rationale for range locking is as a complimentary capability to the
range reads and range writes which are in either the HTTP/1.1 spec. or the
requirements document.  Since locking is designed to address the lost
update problem, a range lock would prevent lost updates resulting from
multiple people performing range writes to the same range.  While a full
resource lock could also prevent the same overwrite scenario, it is more
than is needed.

>I thought the whole point of
>having further meetings and reviews was to discover problems not previously
>exposed.

This is definitely true.  Since I cannot remember the technical problems
identified in range locking at the Irvine meeting, would you (or someone)
care to summarize them for the list?

- Jim

Received on Thursday, 20 February 1997 18:35:01 UTC