W3C home > Mailing lists > Public > w3c-dist-auth@w3.org > October to December 2001

RE: Locking, moving and deleting

From: Stefan Eissing <stefan.eissing@greenbytes.de>
Date: Tue, 2 Oct 2001 15:13:48 +0200
To: "Webdav WG" <w3c-dist-auth@w3c.org>
Message-ID: <NDBBKJABLJNMLJELONBKKEPEDAAA.stefan.eissing@greenbytes.de>
> [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Clemm, Geoff
>
>    From: Lisa Dusseault [mailto:lisa@xythos.com]
>
>    On Behalf Of Clemm, Geoff
>    > The best way to explain the defined MOVE semantics for a LOCK
>    > is to say that a LOCK is on a URL, but that it is deleted
>    > when the resource mapped to that URL is deleted.
>
>    So far I can follow; it's not a bad model.  I'd append "or moved"
>    to the end; most people will consider this different than "deleted"
>    because we have different methods for MOVE and DELETE.
>
> I agree that is worth making explicit to avoid any confusion.
>
>    I don't follow your example as well (reproduced below) because WebDAV
>    doesn't specifically allow for one resource to be mapped by
> several URLs.
>
> WebDAV allows for one resource to be mapped to multiple
> URL's because HTTP specifically allows for one resource to be mapped
> to multiple URL's.  In particular, section 9.6 of RFC 2616:
>
>  "A single resource MAY be identified by many different URIs. For
>  example, an article might have a URI for identifying "the current
>  version" which is separate from the URI identifying each particular
>  version."
>
> Therefore the locking protocol (and the rest of WebDAV) must have
> well defined behavior in those cases where multiple URL's do identify
> the same resource.
>
>    Let's keep it simple and assume that a WebDAV system only maps URLs to
>    resources 1:1.
>
> That's fine, but it is good to keep the multiple mapping scenario in
> mind for when someone suggests a "simpler" model that does
> not handle the multiple mapping scenario.

Well, RFC 2518 Ch. 6 says:
  "The ability to lock a resource provides a mechanism for serializing
   access to that resource. Using a lock, an authoring client can provide
   a reasonable guarantuee that another principal will not modify a resource
   while it is being edited..."

This gave me the impression that locks are on a resource and not
on one particular URL of that resource.

I agree that multiple URL and deep locks on collections provide
some interesting challenges to define consistent behaviour. But
I find it a little bit hard to give up the assumption
   locking resource == locking resource content + properties

So, maybe I have misunderstood this thread?

//Stefan
Received on Tuesday, 2 October 2001 09:13:30 GMT

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