Subject: resourcetype locknull

From: [email-masked]
Date: Wed, 13 Oct 1999 12:38:49 -0400

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: [email-masked] (Geoffrey M. Clemm)
Date: Wed, 13 Oct 1999 13:45:57 -0400

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]
> 
>

---

From: [email-masked]
Date: Wed, 13 Oct 1999 14:39:31 -0400

We should make sure there is a DAV:resourcetype for every resource defined by
the protocol.

[email-masked] on 10/13/99 12:38:49 PM

cc:

---

From: [email-masked]
Date: Thu, 14 Oct 1999 09:23:25 -0400

<jason>
Or LOCK, DELETE (null lock left)...
</jason
<jra>
DELETE on a locked resource does not result in a lock-null resource, the
resource is deleted and the lock is lost.
</jra>

---

From: [email-masked]
Date: Thu, 14 Oct 1999 11:42:34 -0400

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

  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.

This proposal essentially creates a resource and that resource
has special properties... no guid?  special resourcetype?  MKCOL?.  I
guess that could be fine... but it also sounds like it's largely
the same as our current lock null resource.  At least in implementation
and behavior... even if different in conceptual model.

<brainstorm>The thing is, the
goal of this isn't really to create a resource... it's to reserve the
the namespace and perhaps to provide for some atomicity subsequently.
The ideal would be a lock that is rooted in the slot of the parent
collection where the binding resides.  This doesn't fit our current
data model since we never really talk about slots.  This does resolve
a few problems though.  (No, I'm not making a proposal at this point.
Just brainstorming.)
</brainstorm>

---

From: [email-masked]
Date: Thu, 14 Oct 1999 13:14:44 -0400

No it wouldn't, unless we did something with URLs ending in /. Getting ugly
isn't it.

[email-masked] (Albert Lunde) on 10/14/99 11:23:04 AM

Please respond to [email-masked] (Albert Lunde)

To:   [email-masked]
cc:   [email-masked]

Subject:  Re: resourcetype locknull

> 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: [email-masked]
Date: Fri, 15 Oct 1999 15:00:56 -0400

John,
Locking a collection means users that do not own the lock cannot modify the
collection. That is, they cannot add or remove members and cannot modify the
collections properties.

John Stracke <[email-masked]> on 10/15/99 09:44:50 AM

To:   [email-masked]
cc:

"Geoffrey M. Clemm" wrote:

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

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]|                                             |
\==============================================================/