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

> -----Original Message-----
> From: Yaron Goland [mailto:yarong@Exchange.Microsoft.com]
> 
> 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.

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?

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

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

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

Cheers,
Geoff

> 
> > -----Original Message-----
> > From: Clemm, Geoff [mailto:gclemm@Rational.Com]
> > Sent: Thu, February 24, 2000 8:32 PM
> > To: w3c-dist-auth@w3.org
> > Subject: RE: An analysis of the proposal to place locks on 
> URIs rather
> > tha n re sources
> > 
> > 
> > 
> > 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:Edgar.Schwarz@marconicomms.com]
> > > Sent: Thursday, February 24, 2000 5:13 AM
> > > To: w3c-dist-auth@w3.org
> > > 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:geoffrey.clemm@rational.com]
> > > > > 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.
> > > 
> > > -- 
> > > Edgar.Schwarz@marconicomms.com,   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.
> > > 
> > 
>

Received on Friday, 25 February 2000 10:11:08 UTC