RE: MOVEs across file systems

> From: w3c-dist-auth-request@w3.org
> [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Clemm, Geoff
> Sent: Monday, March 10, 2003 8:56 PM
> To: 'WebDAV'
> Subject: RE: MOVEs across file systems
>
>
>
>    From: Julian Reschke [mailto:julian.reschke@gmx.de]
>
>    > From: Jason Crawford
>
>    > We might have to accept that for the single binding cases and
>    > encourage them to do better, but if they don't support cross-file
>    > system bindings and they do a move to another file system and the
>    > source resource also has additional bindings to it from the
>    > original file system, then the request MUST be rejected.  If it
>    > is not, the server can not claim to support the bind spec.
>
>    Well, I think that's up to discussion. MOVE suffers from it's
>    RFC2518 definition (COPY then DELETE). REBIND doesn't. I don't see
>    a problem with a system supporting both (REBIND will fail for some
>    operations, while MOVE won't).
>
> The problem with this approach (leaving the behavior of MOVE and
> DELETE unconstrained in the presence of multiple bindings) is that it
> makes multiple bindings relatively useless, since most people will be
> coming at these advanced servers with legacy clients that support MOVE
> and DELETE, not REBIND and UNBIND.  If you leave the multiple binding
> semantics of MOVE and DELETE undefined, these legacy clients will just
> trash the multiple bindings you've created.
>
> So I'm happy to limit the constraints on MOVE and DELETE to exactly
> what is needed to preserve the semantics of multiple bindings, but
> leaving them unconstrained makes the binding protocol pointless in
> practice.

On the other hand, a system that allows a "weak" MOVE if and only if there
aren't any multiple bindings seems very weird to me. So maybe we should
consider make MOVE "strong" by default, and only allow the old COPY/DELETE
semantics upon specific request?

Julian

--
<green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760

Received on Monday, 10 March 2003 15:03:17 UTC