Subject: Re: resourcetype locknull

From: [email-masked]
Date: Thu, 14 Oct 1999 07:32:11 -0400

<jra>
   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.
<jra>
<Geoff>
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.
</Geoff>
<jra>
We could eliminate lock-null resources, and keep the ability to reserve a name
in the namespace if LOCK on a null resource created a resource with an empty
body and locked it. Since LOCK on a null resource isn't going to respond with
404 Not Found anyway, it might as well create the resource.
</jra>

---

From: "Geoffrey M. Clemm" <[email-masked]>
Date: Thu, 14 Oct 1999 10:23:30 -0400

From: [email-masked]

   <jra>

Having LOCK create a null resource as a side effect?
This can't be "no control coupling" Jim Amsden talking here! (:-).

But seriously, I could easily live with this proposal.  Although I am
aesthetically against control coupling of this kind (i.e. creating a
resource and locking a resource should be two separate and orthogonal
requests), I could live with it if that's what it takes to get rid
of lock null resources.

Cheers,
Geoff

---

From: [email-masked] (Albert Lunde)
Date: Thu, 14 Oct 1999 10:23:04 CDT

> requests), I could live with it if that's what it takes to get rid

But would this work if one intended to reserve a URL to create a collection?

--
    Albert Lunde                      [email-masked]

---

From: "Geoffrey M. Clemm" <[email-masked]>
Date: Thu, 14 Oct 1999 12:41:25 -0400

From: [email-masked] (Albert Lunde)

Albert is of course right.
So I can no longer live with Jim's proposal (:-).

So I'm back to:

   - return a 404 if there is no resource to LOCK,
   - let the client create a "null" instance of what it wants there,
   - then the client locks that null instance and it is off and running.

Cheers,
Geoff

---

From: [email-masked] (WJCarpenter)
Date: Thu, 14 Oct 1999 10:24:50 -0700

gmc> So I'm back to:
gmc>    - return a 404 if there is no resource to LOCK,
gmc>    - let the client create a "null" instance of what it wants there,
gmc>    - then the client locks that null instance and it is off and running.

1.  There is a Very Popular Client which does just about this when
creating a new resource.

2.  The main problem with "lock null resources" is that the spec is a
little weak on exactly what they are.  That causes me as a server
implementor to try to think too hard, when instead I could be having a 
delicious latte on the veranda.  To my mind, this really reduces the
chances of most servers ending up with compatible semantics for this.

3.  OK, how about this implementation?  I grant "lock null resource"
requests, but my server has discretion to vaporize the locks whenever
it wants, and it wants to vaporize them one clock tick after it
creates them.  Bwahh-ha-ha-ha!  Take that, pesky clients!  :-)

4.  I run a lot of applications every day that work with my local
filesystem, and they seem to cope without the equivalent of "lock null
resource".  If there is a namespace collision, which there often is,
I, as a user, deal with that (including the occasional walk to educate
Wally in the next cubicle).  It's an everyday occurrence.  That's what
open() with the O_EXCL flag is all about, right?  Could it be
paralleled in WebDAV with either (a) expanded use of the OVERWRITE:
header, or (b) HTTP/1.1 PUT, etc, with "IF-NONE-MATCH: *"?
-- 
[email-masked]   (WJCarpenter)           PGP
[email-masked]                    0x91865119
38 95 1B 69 C9 C6 3D 25  73 46 32 04 69 D6 ED F3

---

From: John Stracke <[email-masked]>
Date: Fri, 15 Oct 1999 09:44:50 -0400

>    - then the client locks that null instance and it is off and running.

For collections, this doesn't work properly with your/Alan's proposal for static
depth locking.  If I'm creating a collection, I do LOCK (404), MKCOL, LOCK--but
this LOCK only locks the resources that are there now (i.e., none).  So anybody
else is free to come along and add new resources, and my lock means nothing.  For
collections that are meant to model compound documents or some such, where the
entire state of the collection needs to be treated as a unit, this is a Bad Thing.

--
/==============================================================\
|John Stracke    | http://www.ecal.com |My opinions are my own.|
|Chief Scientist |=============================================|
|eCal Corp.      |Illiterate? Write today for free help!       |
[email-masked]|                                             |
\==============================================================/

---

From: "Geoffrey M. Clemm" <[email-masked]>
Date: Fri, 15 Oct 1999 10:25:28 -0400

From: John Stracke <[email-masked]>

   >    - then the client locks that null instance and it is off and running.

   For collections, this doesn't work properly with your/Alan's proposal
   for static depth locking.  If I'm creating a collection, I do LOCK
   (404), MKCOL, LOCK--but this LOCK only locks the resources that are
   there now (i.e., none).

Your lock on the collection locks the state of that collection, i.e.
the bindings.  That means that only someone with the lock can modify
the state of that collection, such as adding new bindings to it.

   So anybody else is free to come along and add
   new resources, and my lock means nothing.

Not unless they have the lock.  See above.

   For collections that are
   meant to model compound documents or some such, where the entire state
   of the collection needs to be treated as a unit, this is a Bad Thing.

As long as you partition the compound object clearly into disjoint
pieces, and provide a mechanism for locking each of those pieces
(including the pieces that glue the other pieces together, i.e. the
collections!), then you can effectively treat it as a unit by locking
"every piece".  The problem with the current state of locking in 2518
is that the various locks overlap in various complex ways, making the
interaction between locks hard for clients to predict and hard for
servers to implement.  But I think that we can adjust the protocol to
remove this locking overlap in a way that makes it largely consistent
with the existing clients and servers.

Cheers,
Geoff