RE: Locking a Resource or Locking a URL?

I'm not sure that I understand what you are suggesting, so let me ramble a
bit and perhaps you will see where I am confused . . .

Yaron (I think) suggested at one point that we treat references the way
WebDAV treats source.  So we would introduce a new property on the reference
similar to the DAV:source property on ordinary resources.  In order to apply
any method to the reference, a client would have to get the URI from this
new property and submit the request to that URI.

This mechanism would replace the No-Passthrough header currently in the
advanced collections protocol.

This would work if the default behavior for every method was to apply to the
target.  Then any request submitted to the URI that identifies the reference
would get applied to the target, and to apply the request to the reference
you would send it to the URI in DAV:ref.  

But currently there are exceptions, for which the default behavior -- the
one we want down-level clients to get -- is to apply the request to the
reference.
 
We always want to make it possible for reference-aware clients to override
the default behavior, and have the request applied to the reference or the
target or both.  No-Passthrough lets the client have the method applied to
the reference; looking up the value of DAV:reftarget and submitting the
request to it allows the client to have the method applied to the target.

Are you suggesting that each reference contain instructions for the default
behavior of each method? So the protocol would specify a syntax for setting
up these instructions, and each individual reference could have a different
default behavior?  Or that the server would decide on the default behavior
and the client could somehow discover what it is?

--Judy

> -----Original Message-----
> From: Roy T. Fielding [mailto:fielding@kiwi.ics.uci.edu]
> Sent: Thursday, March 04, 1999 4:17 AM
> To: Slein, Judith A
> Cc: w3c-dist-auth@w3.org
> Subject: Re: Locking a Resource or Locking a URL? 
> 
> 
> >A reference is a resource, as is its target.  They are just 
> two different
> >resources.  The issue the design team was addressing was 
> which resource(s)
> >get(s) locked when you send a LOCK request with a request-URI that
> >identifies a reference.
> >
> >I think the design team agreed that the most intuitive 
> behavior in this case
> >would be for both the reference resource and the target 
> resource to be
> >locked.  The design team let some other consistency 
> considerations over-ride
> >the law of least surprise in this case.  We ended up with 
> the position that
> >for redirect references, just the reference gets locked; and 
> for direct
> >references, just the target gets locked.
> 
> I think it might be useful to take a step back and ask why any of the
> "operations on the reference" are being applied to the same URL as the
> "operations on the target of the reference".  This is the 
> same relationship
> that exists between the source of a CGI script and the URL(s) 
> that cause
> the CGI script to be executed.
>
> In other words, create/write/lock the reference at URL "R", have it
> contain the instructions for
> 
>      {URL set not including R} --> target URL
> 
> and let the server take care of the magic of making it so.
> The ambiguity goes away.  Furthermore, a smart definition would
> allow the reference to be defined according to the media type (with
> one type being the preferred standard), thus allowing extensions
> to author smarter, more flexible alternatives (like 
> mod_rewrite rules).
> 
> ....Roy
>

Received on Tuesday, 9 March 1999 17:25:29 UTC