Subject: Re: resourcetype locknull

From: [email-masked]
Date: Wed, 13 Oct 1999 14:48:53 -0400

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?

[email-masked] (Geoffrey M. Clemm) on 10/13/99 01:45:57 PM

To:   [email-masked]
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 [email-masked] Wed Oct 13 12:36 EDT 1999
> Resent-Date: Wed, 13 Oct 1999 12:35:25 -0400 (EDT)
> Resent-Message-Id: <[email-masked]>
> From: [email-masked]
> X-Lotus-Fromdomain: IBMUS
> To: [email-masked] (w3c-dist-auth)
> Date: Wed, 13 Oct 1999 12:38:49 -0400
> Mime-Version: 1.0
> Content-Disposition: inline
> Subject: resourcetype locknull
> Resent-From: [email-masked]
> X-Mailing-List: <[email-masked]> archive/latest/3441
> X-Loop: [email-masked]
> Resent-Sender: [email-masked]
>
>
> 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,   [email-masked]
>
>

---

From: "Geoffrey M. Clemm" <[email-masked]>
Date: Wed, 13 Oct 1999 15:47:50 -0400

From: [email-masked]

   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.

Isn't this functionally equivalent to someone getting the lock on the
lock null resource between the time when you issued the lock request
and the time it was handled by the server?  The fact that they got the
lock on the empty dummy resource you created, as opposed to a lock on a
"lock null" resource doesn't seem to change the situation in any
substantive way.

(Jim: Since you don't like lock null resources anyway, you shouldn't
feel compelled to answer this ... this question is intended for
anyone who *is* in favor of lock null resources :-)

   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.

Yup, to all Jim says here.

   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.

Oh, still pretty ambivalent ... (not :-).

Cheers,
Geoff

---

From: John Stracke <[email-masked]>
Date: Wed, 13 Oct 1999 18:00:06 -0400

> "lock null" resource doesn't seem to change the situation in any

Consider what happens if you need to create a resource with a particular
body and some particular properties.  If you don't have lock-nulls (or
transactions), then you do PUT, LOCK, PROPPATCH, UNLOCK (or maybe skip the
LOCK/UNLOCK, since it's only protecting one operation).  If you and
somebody else are trying to create it at the same time, then you could get
PUT1, PUT2, PROPPATCH2, PROPPATCH1, resulting in resource whose properties
don't match its body.  With lock-null, you can do LOCK, PUT, PROPPATCH,
UNLOCK.

--
/==============================================================\
|John Stracke    | http://www.ecal.com |My opinions are my own.|
|Chief Scientist |=============================================|
|eCal Corp.      |Never mind the GUIs--Unix won't be for the   |
[email-masked]|masses until we fix backspace & delete.      |
\==============================================================/

---

From: "Geoffrey M. Clemm" <[email-masked]>
Date: Wed, 13 Oct 1999 23:08:16 -0400

From: John Stracke <[email-masked]>

   Consider what happens if you need to create a resource with a particular
   body and some particular properties.  If you don't have lock-nulls (or
   transactions), then you do PUT, LOCK, PROPPATCH, UNLOCK

Actually, since you don't know whether or not something is there
already, you'd always first try the LOCK.  If the LOCK fails (because
there is no resource there to LOCK), you do a PUT (with an empty body)
followed by a LOCK.

So what you do is:

LOCK (if fail because no resource there, then PUT null-body; LOCK)
PUT; PROPATCH; UNLOCK

So all LOCK-NULL buys you is the avoidance of the extra PUT/LOCK in
case there is no resource there yet.

   (or maybe skip the
   LOCK/UNLOCK, since it's only protecting one operation).

Even if you just did a single operation, you still want the
LOCK/UNLOCK to prevent another (locking) client from performing
its edits using the state of the resource prior to your
operation (i.e. you don't want to "lose" your operation).

   If you and

Without lock null resources, you still wrap LOCK/UNLOCK around
your sequence of operations.  The only difference is that if your
LOCK fails because there is no resource to LOCK, you issue a PUT
with an empty body, followed by a retry of the LOCK.

Note: If someone gets in ahead of you and locks the dummy resource
you just created, that's no different than someone getting their
lock-null LOCK request in ahead of you.

Note 2: Hopefully there are some GET's and PROPFIND's mixed in
with those PUT's and PROPPATCH's, or else you're going to lose
the previous updates, whether or not you use LOCK's.

Cheers,
Geoff

---

From: Jim Whitehead <[email-masked]>
Date: Thu, 14 Oct 1999 17:41:53 -0700

> don't match its body.  With lock-null, you can do LOCK, PUT, PROPPATCH,

This is a pretty good restatement of the original rationale for lock-null
resources.

Given the preponderance of evidence that indicates this is a difficult
feature to implement, and since the arguments claiming that the feature is
not strictly necessary appear to be sound, I would be happy to remove this
feature as we move from Proposed to Draft standard, assuming that doing so
does not create any interoperability problems.

Yaron's currently on vacation, he may wish to defend this feature when he
returns. I'm certainly not going to, unless I hear a compelling counter
argument.

- Jim