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

AltStyle によって変換されたページ (->オリジナル) /