Subject: RE: An analysis of the proposal to place locks on URIs rather tha n re sources

From: "Clemm, Geoff" <[email-masked]>
Date: Thu, 24 Feb 2000 23:32:11 -0500

I'll answer Edgar's question immediately, since it is nice and short ...
I will respond to Yaron's post later since it is nice and long (:-).
But my answer to Edgar and my response to Yaron have the same basis,
namely that when I said "a lock is on a URL", I was really saying a lock
"acts" like it is on a URL.  The fact that a lock is *really* on a
resource is detailed in the GULP (Grand Unified Locking Proposal).
In particular, it is really on the first WebDAV collection encountered
on the path.  It is then just inherited by resources below.

But before this goes too much farther, I should state that GULP was
a somewhat academic exercise to develop a complete model that would
provide consistent answers to all the depth locking, null resource
locking, and URL protection issues that have arisen on the mailing
list.

My conclusion is that we just have to simplify.  In particular, I believe
we have to keep URL protection, but that depth locking and null resources
must go in order to have a locking model that will be be implementable
and understandable in conjunction with protocol extensions such as bindings
and versioning.

And in a Simple LOcking Proposal (SLOP :-), locks will be back to being
on resources, which Yaron will like, until he hears that this means that
a lock should move with a resource when that resource is MOVE'd, which
he will vigorously protest against (if he has time to do so :-).

Cheers,
Geoff

> -----Original Message-----
> From: Edgar Schwarz [mailto:[email-masked]]
> Sent: Thursday, February 24, 2000 5:13 AM
> To: [email-masked]
> Subject: Re: An analysis of the proposal to place locks on URIs rather
> than re sources
> 
> 
> Yaron Goland wrote:
> 
> Sorry, no time for a comment to Yaron's stuff at the moment :-)
> 
> > > From: Geoffrey M. Clemm [mailto:[email-masked]]
> > > Sent: Thu, December 30, 1999 2:33 PM
> 
> > > As an addendum to Yaron's response, I'll note that there 
> is a proposal
> > > that WebDAV locking is better understood as locks on 
> URL's rather than
> > > on resources.
> I'm not sure I understand. Does that mean that you can't lock 
> a resource
> anymore with WebDAV ?
> I wouldn't like this idea. Or do you propose another mechanism for
> locking a resource ?
> 
> Cheers, Edgar
> 
> P.S. Sorry if this topic was already solved in the meantime 
> but I didn't
> have time to follow the discussions for a while.
> 
> -- 
> [email-masked],   Marconi Communications,  
> 07191/13-3382
> Privat kann jeder soviel C programmieren oder Videos ansehen 
> wie er mag.
> Albert Einstein:  Mach es so einfach wie moeglich, aber nicht 
> einfacher.
>

---

From: Yaron Goland <[email-masked]>
Date: Thu, 24 Feb 2000 22:28:21 -0800

The only reason I don't like moving locks on resources is that many existing
systems CAN NOT do it. So if you define it then the Windows world will
ignore WebDAV and implement what it's system can actually support.

In the purely theoretical sense I have no problem with locks moving with a
resource, so long as the lock owner is the one who did the move.

BTW, I bet you still end up with a NULL resource or the moral equivalent.

> From: Clemm, Geoff [mailto:[email-masked]]
> Sent: Thu, February 24, 2000 8:32 PM
> To: [email-masked]
> Subject: RE: An analysis of the proposal to place locks on URIs rather
> tha n re sources
> 
> 
>

---

From: "Clemm, Geoff" <[email-masked]>
Date: Fri, 25 Feb 2000 09:58:51 -0500

> From: Yaron Goland [mailto:[email-masked]]
> 

Is this really "cannot" or just "currently do not".  I understand that
the underlying file system lock has whatever semantics it has, and is
unlikely to change, but could not the HTTP MOVE method be defined to
re-establish the lock following the move?

> resource, so long as the lock owner is the one who did the move.

Yes, I agree that the lock token must be included in the request
in order for the MOVE to succeed.  The question of whether only
the "lock owner" can use the lock token is a separate one that is
the topic of a different thread.

> BTW, I bet you still end up with a NULL resource or the moral 

I'll take that bet ...  loser buys dinner at the next IETF
meeting (:-).

Cheers,
Geoff