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

RE: Locking a Resource or Locking a URL?

From: Yaron Goland <yarong@microsoft.com>
Date: Fri, 26 Feb 1999 12:25:39 -0800
Message-ID: <3FF8121C9B6DD111812100805F31FC0D08792FA4@RED-MSG-59>
To: "'Jim Davis'" <jdavis@parc.xerox.com>, w3c-dist-auth@w3.org
A reference is a resource. A target is a resource. A reference and its
target are two different resources.

The example below only applies to a resource with two names. It does not
necessarily apply to a reference and its target because these are two
separate resources.

However, because a reference masquerades as the target for down level
clients it is necessary to carefully control the reference's behavior in
order to ensure that down level client expectations are met. Please refer to
the thread on LOCK and references for an excellent example of where these
expectations can clash with reality.

		Yaron

> -----Original Message-----
> From: Jim Davis [mailto:jdavis@parc.xerox.com]
> Sent: Friday, February 26, 1999 9:21 AM
> To: w3c-dist-auth@w3.org
> Subject: RE: Locking a Resource or Locking a URL?
> 
> 
> At 10:34 PM 2/25/99 PST, Yaron Goland wrote:
> >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, this is a really great question because it exposes an 
> underlying
> conceptual unclarity [*] that has been plaguing our 
> discussion for months.
> 
> Is a direct reference 
>  1. a *synonym* for the resource it points to, or
>  2. a *resource* (albeit one whose semantics are defined so 
> as to make it
> act, in almost all cases, like a synonym.)
> 
> When you write about "two names [for the same resource]", 
> you're using the
> "synonym" metaphor, and I think this is why you are lost. 
> 
> For most operations, there's no difference between these two. 
>  They act the
> same.  But the locking discussion exposes one such 
> difference, so now we
> have to decide.
> 
> If a reference is a synonym, then it just makes no sense to 
> speak of a lock
> on the "reference" that is not on the "target".   They are 
> just different
> names for the same thing.   If a reference is a resource, 
> then it at least
> makes sense to speak of distinct locks.  It may or may not be 
> the *right*
> design choice, but at least one can talk about it.
> 
> I think our discussion to date has mostly, but not entirely, 
> been based on
> the assumption that a reference is in fact a second resource. 
>  But it's
> never been clearly settled.  But note, for instance, the 
> discussion on your
> issue #5, proposing a complex value for the DAV:resourcetype 
> property of
> the reference.  If a reference were merely a synonym, this 
> wouldn't make
> sense.
> 
> If a reference is in fact a distinct resource from the 
> target, then it's
> possibe, at least in principle, to have different locks on 
> the reference
> and on the target.  You could decide that the protocol should 
> be such that
> a lock on the reference always must also lock the target, 
> and/or that a
> lock on the target must also lock (all) references to it.  
> These are at
> least conceptually separable design choices.
> 
> If you want to push on the "synonym" interpretation, then 
> there is a second
> issue that arises, but I won't go into it now.  
> 
> [*] One can trace this unclarity back to some old problems in 
> philosophy of
> language.  Is "the morning star" the same object as "the 
> evening star"?  Is
> "the president of the united states" the same person as "Bill 
> Clinton"?
> How fortunate we are that the design team is led by one 
> actually trained as
> a true philosopher.  You may think WebDAV had to face some 
> ratholes, but I
> tell you that Wittgenstein is to these rats as Moby Dick is 
> to a trout.
> 
> trying to swim
> 
> Jim
> 
Received on Friday, 26 February 1999 15:25:49 GMT

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