RE: MOVEs across file systems

> From: w3c-dist-auth-request@w3.org
> [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Jason Crawford
> Sent: Monday, March 10, 2003 7:58 AM
> To: Lisa Dusseault
> Cc: 'WebDAV'
> Subject: MOVEs across file systems
>
>
>
>
>
>
> BTW... I just had an interesting thought about MOVE's across file systems.
> We've been talking about having to do that as a COPY/DELETE.  And on
occasion
> we've said that it truly isn't necessary to actually move the resource
> implementations as long as they respond at the right URL's.  For the most
> part though, that comment has felt a bit academic to me.
>
> Anyway... the thought I just wanted to point out is that if you have a
> resource on one file system with multiple bindings to it, and you MOVE
> that resource via one of those bindings "to another file system"...
> you might actually want to NOT "copy/delete" it since you still also have
> several bindings to it from the original file system.  You might
> *need* to keep a cross file system binding and not necessarily
> move implementations around during MOVE/BIND and other
> namespace operations.  And if you're forced to support cross
> file system bindings, then perhaps you never really need to take the
> COPY/DELETE approach?
>
> Anyway... it's just a stray thought.  :-)

Jason,

that's one of the reasons why I think we'll need REBIND in addition to MOVE,
unless we can get a consensus that MOVE should indeed behave as REBIND.

If you have a system that supports BIND and multiple bindings, but not
across the full namespace (the common example with multiple filesystem
backends, where you don't want to add an additional layer on top of the
basic FS functionality). Let /a and /b represent namespace partitions that
reside in different filesystem partitions. An obvious approach would be just
to mirror what the filesystem backend allows -- a BIND within /a would work,
while a BIND from /a to /b would fail (same for REBIND). However, a client
that doesn't expect this error condition would still be able to MOVE the
resource. In this case, the resource at the target URL of the MOVE request
would *not* be the "same" resource anymore (it would have a different
DAV:resource-id).

Julian

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

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