Subject: RE: Creating a lock-null in a locked collection

From: Yaron Goland <[email-masked]>
Date: Mon, 3 Jan 2000 10:35:46 -0800

Geoff said: "It sometimes acts like a resource (modifies the parent
collection), and sometimes does not (returns a 404 when you GET it)."

In HTTP, as I understand it, one sends a method to a resource identified by
a URI. As such any response one gets must have come from a resource.
Therefore a 404 must be issued by a resource. This is why the object model I
suggested for WebDAV has the universal NULL resource that handles things
such as issuing 404s. As such how can one say that because a resource issues
a 404 it is not acting like a resource?

			Yaron

> -----Original Message-----
> From: Geoffrey M. Clemm [mailto:[email-masked]]
> Sent: Thursday, December 30, 1999 7:35 PM
> To: [email-masked]
> Subject: Re: Creating a lock-null in a locked collection
> 
> 
> 
>    From: Joe Orton <[email-masked]>
> 
>    ... It just seemed slightly weird, that if you LOCK or UNLOCK a
>    lock-null resource, you are modifying the state of the 
> parent collection;
>    when if you do the same to a normal resource, you are not.
> 
> Yes, that is one of the reasons I strongly object to the notion of a
> "lock null resource".  It sometimes acts like a resource (modifies the
> parent collection), and sometimes does not (returns a 404 when you GET
> it).  This makes it very hard to predict what its behavior should be
> whenever you extend the protocol (i.e. should it act like a resource,
> or act like not a resource).  For example:
> 
> - the BIND protocol (can you "BIND" a lock null resource to
>   another URL?)
> - the versioning protocol (do you have to checkout a 
> versioned collection
>   in order to add a lock null resource to it?)
> 
> Cheers,
> Geoff
>

---

From: [email-masked]
Date: Tue, 4 Jan 2000 13:48:23 -0500

I think the point is that if the WebDAV locking model is too strange, it
will be hard to reconcile the WebDAV locking mechanism with the other
locking mechanisms.  Introducing new concepts like lock-null's makes it
much
more difficult and less intuitive to reconcile in this way.
I agree that that was the real point in regard to LNR's.  I think most of
us are willing
to accept that complication if there is also sufficient benefit derived
from it, but based on previous discussions, it doesn't seem folks value
LNR's very much.

Perhaps we should discuss other locking mechanisms in filesystems and
RDBMS's to validate this.
Sounds good.

My understanding is that both Windows & UNIX filesystems lock all of the
names in a directory when the directory is explicitly locked (via
lockf()/flock() or something similar).
If so, that's fortunate because it's what all recent proposals have
suggested.
I don't think this is the case on Unix though (except by convention)
because
the locks there appear to be advisory.  I haven't tried any *directory*
locking in Windows but what you suggest sounds likely.

  In Windows filesystems, this
guarantees that the name cannot change since each file can be in only one
directory.
On Linux anyone can come along and modify or delete/unlink the (f)locked
resource.  The (f)locks are purely advisory... but are on the resource
itself.  That is, the locks don't prevent operations like
read/write/delete/etc... only other attempts to lock the resource.  And
those attempts to exclusively lock will fail no matter which filename is
used to specify an already locked resource.  -- FWIW, UNIX does  have
shared and exclusive locks.  They don't have read vs. write locks... but
essentially the exclusive lock is a "write" lock and the shared lock is a
"read" lock by convension.  Anyway, my point here is that the lock is on
the resource... and the path is in no sense protected.

On Windows, that's not the case.  Both the resource and the URI path are
locked.. but I haven't seen Windows do multiple bindings in the FS, so
that may change/refine the story here.

Anyone savvy in Window or Unix should feel free to correct me on any of
this.  All of the above is the result of both reading and testing.

Jason.