RE: Locking a Resource or Locking a URL?

O.k. I'm completely lost. Let's try this again.

I have a resource which is available through two names, http://foo/bar and
http://iggy/pop. Someone requests and receives an exclusive write lock
against http://foo/bar. I assert that the immediate consequence is that
http://iggy/pop is ALSO write locked by the same principal.

			Yaron

> -----Original Message-----
> From: Geoffrey M. Clemm [mailto:gclemm@tantalum.atria.com]
> Sent: Thursday, February 25, 1999 10:28 PM
> To: Yaron Goland
> Cc: w3c-dist-auth@w3.org
> Subject: Re: Locking a Resource or Locking a URL?
> 
> 
> 
>    From: Yaron Goland <yarong@microsoft.com>
> 
>    [Larry, stop laughing.]
> 
> [Actually, keep laughing ... a little laughter it's good for the soul
>  ... now we just have to figure out which of us he's laughing at :-]
> 
>    You perceive a differentiation where none exists. URLs 
> exist solely to
>    address resources. That a resource has multiple URLs is 
> irrelevant. When a
>    method is sent to a URL the end result is an interaction 
> with a resource.
> 
> I agree.
> 
>    Thus, using your language, #2 is correct.
> 
> One of us has stayed up too late (:-).  #2 says (and I quote :-):
> "if the resource currently selected at that URL also appears at
>  another URL, then the lock does not apply to accesses through
>  that other URL"
> 
> So aren't you saying that you agree with me that #2 is *incorrect* ?
> 
>    Any other interpretation would
>    mean that someone locking a resource through one URL could 
> still see the
>    resource changed simply because someone addressing the 
> same resource through
>    another URL made a change.
> 
> Right.  That's what #2 says, and that would be silly.  So #2 is wrong.
> 
>    I believe the WebDAV spec to be crystal clear on
>    this point but if somehow the language has lead you astray 
> please point out
>    the language that confused you and I will make sure it is 
> properly edited
>    before we move on to draft status.
> 
> Well, assuming you agree that #2 is wrong, I agree that the 
> spec is clear
> on the "wrongness of #2".
> 
> The *important* part of the discussion only comes when we 
> chose between
> #1 and #3, but I'll wait for you to confirm that #2 is definitely out.
> 
> Cheers,
> Geoff
> 
>    > -----Original Message-----
>    > From: Geoffrey M. Clemm [mailto:gclemm@tantalum.atria.com]
>    > Sent: Thursday, February 25, 1999 8:35 PM
>    > To: w3c-dist-auth@w3.org
>    > Subject: Locking a Resource or Locking a URL?
>    > 
>    > 
>    > 
>    > One of the key topics in the recent thread on the Adv. 
>    > Versioning Collection
>    > protocol was the question of what gets locked when you lock a 
>    > resource.
>    > 
>    > There are (at least :-) three interpretations:
>    > 
>    > (1) You are locking only the resource.
>    > 
>    > (2) You are locking what appears at a given URL (i.e. if 
> the resource
>    > currently selected at that URL also appears at another 
> URL, then the
>    > lock does not apply to accesses through that other URL).
>    > 
>    > (3) You are locking both the resource and the fact that 
> the resource
>    > appears at the given URL.
>    > 
>    > In my message in the Adv. Coll. thread, I gave arguments for why
>    > (3) does not work in the context of references and versioning.
>    > 
>    > In this message, I would like to confirm that nobody 
> believes that
>    > (2) is the correct interpretation.  In particular, I 
> would like to
>    > confirm that if /a/x.html and /b/y.html happen to be the 
> same resource
>    > (by some quirk of the server, say), and /a/x.html is locked, then
>    > a PUT to /b/y.html would fail without the appropriate lock token.
>    > 
>    > There also is the question of whether lock discovery 
> would detect this
>    > implicit lock on /b/y.html.  This question has two parts 
> ... what do
>    > you think the spec currently says, and what did the spec authors
>    > intend?
>    > 
>    > Cheers,
>    > Geoff
>    > 
>    > 
>

Received on Friday, 26 February 1999 01:34:55 UTC