Re: resourcetype locknull

Lock-null resources were introduced to allow a user to "reserve" a name in the
namespace. That is, to sort of create the resource and lock it in a single
method. Otherwise, there is a race condition between the time the resource is
created and the time it is locked where some other user could get the lock or
otherwise change the new resource. Lock-null resources represent an attempt to
special case situations that arise from the need to have transaction semantics
and stateful servers for distributed authoring. There are other cases (in the
versioning spec too) where methods are overloaded with headers (control couples)
to make them do something that could have been done with a number of other
methods, but not atomically. There's also the argument of reducing round trips,
but this is pretty limited in this case. HTTP can execute a lot of methods in a
second, and authoring environments often have much lighter nonfunctional
requirements that production server systems.

It was a real pain to implement lock-null resources as it is full of special
cases. I too would just as soon see it removed from the spec. It doesn't seem
that the complexity it adds to the protocol is consistent with the potential
problem it solves.

But Geoff, how do you reall feel about lock-null resources?





gclemm@atria.com (Geoffrey M. Clemm) on 10/13/99 01:45:57 PM

To:   w3c-dist-auth@w3.org
cc:

Subject:  Re: resourcetype locknull




Could someone *pleeeassse* tell me what problem "lock null" resources
are supposed to solve?  I found a message from Yaron dated 3/22/98 where
they appear to be introduced by an analogy with the need for "zero"
when you are counting.  I am not convinced (:-).

If you want to "lock" a place where there is no resource, create some
dummy resource there and lock that.

Currently we're stuck with several paragraphs of verbiage telling us
how a lock null resource behaves exactly like a regular resource except
that it returns a "404" when you try to get its body.  Is that feature
so important that it warrants the incremental complexity and confusion
that it adds to the spec?

I propose that we strike all references to "lock null" resources in
2518.

Note: Unlike my previous more radical non-proposal (which by the way is
still what I wish we would do :-), this is a serious proposal.

Cheers,
Geoff

> From w3c-dist-auth-request@w3.org Wed Oct 13 12:36 EDT 1999
> Resent-Date: Wed, 13 Oct 1999 12:35:25 -0400 (EDT)
> Resent-Message-Id: <199910131635.MAA02545@www19.w3.org>
> From: ccjason@us.ibm.com
> X-Lotus-Fromdomain: IBMUS
> To: w3c-dist-auth@w3.org (w3c-dist-auth)
> Date: Wed, 13 Oct 1999 12:38:49 -0400
> Mime-Version: 1.0
> Content-Disposition: inline
> Subject: resourcetype locknull
> Resent-From: w3c-dist-auth@w3.org
> X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/3441
> X-Loop: w3c-dist-auth@w3.org
> Resent-Sender: w3c-dist-auth-request@w3.org
>
>
> I've noted it in the lock issues list and I suspect Jim already has it in the
> 2518 issue list, but in the definition section it says that lock-null
resources
> are not listed as children of their parent... and (by omiision) cannot accept
> UNLOCK and PROPFIND methods.  Later in the document it says the opposite.   I
> believe the later information is correct.
>
> Based on that assumption and a "problem" I encountered with LOCK support in
the
> Linux version of mod_dav, I'd like to propose   "lock-null" as a potential
value
> for the resourcetype property.  This will give clients a predictable value
there
> for lock-null resources.
>
> What is the "problem" in linux mod_dav?  Well it claims that the lock-null
> resource is a collection.  That's not technically incorrect.  So I'd like to
> insure that we specify exactly what is returned for the sake of clients.  And
it
> seems like a new value would be appropriate.
>
> ------------------------------------------
> Phone: 914-784-7569,   ccjason@us.ibm.com
>
>

Received on Wednesday, 13 October 1999 14:57:26 UTC