Re: new proposed text for locking overview

Geoffrey M Clemm wrote:

> ...
> The context is just the rest of the paragraphs of Julian's proposed
> text, but I'll include it again below.  By "significant improvement",
> do you mean "I now like it", or are there remaining problems that you
> see in the proposed text (quoted below, with the first two sentences
> changed to avoid calling a lock a resource):
> 
> -----------------------
> 
> 2.5 Status of a lock
>    A lock is identified by a URI (the lock token URI) but in general, it
>    does not have a HTTP URL, and thus can not be directly manipulated using
>    HTTP methods.  Instead, this specification defines the new methods
>    LOCK (creating and refreshing locks, see Section 4) and UNLOCK
>    (removing locks, see Section 5) that act indirectly on locks.
> 
>    A lock has state that can be indirectly observed by using the
>    DAV:lockdiscovery property defined in Section 3.2.  At a minimum, the
>    state of a lock consists of the items defined in the sections below.
>    After lock creation, all parts of the state with the exception of the
>    timeout value are immutable.
> 
> ...
> 
> Does anyone have any issues with this revised text?

I just updated my draft accordingly.

Note that the purpose of this proposal was *not* to start a discussion 
about the resource-ness of locks, but to collect information about the 
state a lock has into a single place. That was mainly caused by the 
observation that RFC2518 spreads lots of information about things like 
owner and timeout information across the document, making it hard to 
find a definitive summary. *Having* that summary allows to remove 
significant amounts of text from other places (where they IMHO shouldn't 
have been in the first place).

Best regards, Julian

-- 
<green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760

Received on Thursday, 8 July 2004 18:35:12 UTC