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

Re: Should REBIND preserve locks, other live properties

From: Geoffrey M Clemm <geoffrey.clemm@us.ibm.com>
Date: Tue, 23 Mar 2004 11:12:16 -0500
To: Webdav WG <w3c-dist-auth@w3c.org>
Message-ID: <OFF34CFD9F.C7037E91-ON85256E60.0058B48A-85256E60.0058F3F9@us.ibm.com>

I agree with Julian that point of REBIND/UNBIND is (and has always been)
to define an atomic form of MOVE/DELETE.

The only point at which we differ is that he might be interested in
supporting a lock-preserving RENAME method, while I am not (:-).


Julian Reschke <julian.reschke@gmx.de> wrote on 03/22/2004 03:31:13 PM:

> Lisa Dusseault wrote:
> > 
> > So if REBIND is the same as MOVE in all cases, why are we defining it?
> It isn't 
> (<http://greenbytes.de/tech/webdav/draft-ietf-webdav-bind-04.
> "The REBIND method removes a binding to a resource from one collection, 
> and adds a binding to that resource into another collection. It is 
> effectively an atomic form of a MOVE request."
> > I reject the argument that this behavior is needed for REBIND as well 
> > as MOVE for client convenience.  MOVE would remain as defined for 
> > clients that want the convenience of keeping URL/Lock-token pairs 
> > unchanged.  A new method, like RENAME, could provide clients a 
> > completely optional method with different convenience tradeoffs: the 
> > convenience of not having to issue a new LOCK request if further 
> > resource changes are required, etc.  That's what I thought the 
> > intent of REBIND was.
> Well, it isn't. If you feel that there should be a method allowing 
> namespace manipulation while maintaining locks, you're free to work on 
> it (I may even be interested on supporting it, once it's defined).
> But this wasn't on the requirements list for BIND, and IMHO nobody has 
> asked for it recently, so it doesn't belong into BIND. It's a completely 

> separate issue.
> Regards, Julian
> -- 
> <green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760
Received on Tuesday, 23 March 2004 11:12:58 UTC

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