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:28:21 UTC