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

Should REBIND preserve locks, other live properties

From: Lisa Dusseault <lisa@osafoundation.org>
Date: Thu, 18 Mar 2004 16:05:14 -0800
Message-Id: <18F94BB3-7939-11D8-BB68-000A95B2BB72@osafoundation.org>
To: Webdav WG <w3c-dist-auth@w3c.org>

In RFC2518, a MOVE operation is supposed to destroy all locks on the 
moved resource and any descendants.  This behavior is unlike most 
filesystems.  Yaron laid out the reasons but they weren't too strong.  
Basically the reasons why not amounted to the fact that some systems 
that didn't support bindings couldn't do this easily.

I'd assumed that a REBIND was different than MOVE, and couldn't be used 
in as many cases.  If a REBIND is really the same as a MOVE then why 
are we defining it?  If it's different -- e.g. if , as I had assumed, 
REBIND is "safer" and more high-fidelity than MOVE (but can be used in 
fewer cases) then we need to understand how it's different.

If REBIND can be different than MOVE, then we can make a number of 
things work better (more predictable) from a client point of view:
  - locks aren't destroyed, lock token doesn't change, the lock state 
appearing on other bindings doesn't change
  - getlastmodified date doesn't change unless another resource is 
overwritten (for that matter, we could specify that REBIND can't 
overwrite another binding which would make it even simpler), so the 
getlastmodified date on other bindings doesn't change
  - etag doesn't change...
  - live properties have more guarantees in how they are preserved
  - ACLs aren't re-inherited?
  - this makes a "rename" operation work exactly as the client expects 
it would (not the case today with MOVE)

If a server can't implement REBIND -- well, there's still MOVE.

Received on Thursday, 18 March 2004 19:05:30 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 20:01:31 UTC