W3C home > Mailing lists > Public > w3c-dist-auth@w3.org > January to March 2000

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

From: Yaron Goland <yarong@Exchange.Microsoft.com>
Date: Thu, 24 Feb 2000 22:28:21 -0800
Message-ID: <7DE119D3D0E15543874F7561EECBDBED030B541C@BEG.platinum.corp.microsoft.com>
To: "'Clemm, Geoff'" <gclemm@Rational.Com>, w3c-dist-auth@w3.org, "'yaron@goland.org'" <yaron@goland.org>
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.

> -----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 01:56:55 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 2 June 2009 18:43:54 GMT