Re: Move and Delete (was: bind draft issues)

On Friday, March 7, 2003, at 12:57  AM, Julian Reschke wrote:
[snip]
> Yes and no. I really think that there may be separate use case that 
> require
> separate solutions.
>
> A client should be able to request a MOVE operation that will fail if 
> the
> server can't support full MOVE semantics (for instance by changing the
> DAV:resource-id property). A client would then be able to reconsider,
> possibly issuing a COPY/DELETE sequence instead.
>
> Hopefully we can agree that this type of request should be supported. 
> If we
> do, we're left with the alternatives of making this the standard 
> behaviour
> for the RFC2518 MOVE, or to invent some new marshalling. I'd prefer the
> former, but I probably could live with the latter.
>
> A similar problem obviously exists with the DELETE collection atomicity
> issue.

Julian,

We are in agreement here.

Even if a server is able (or desirable) to support atomic operations
in some cases, there needs to be a way for these servers to communicate
to clients when an atomic operation cannot be performed so that
the client can retry using the non-atomic operation (if so desired).
MOVEs across unix file systems are one example, but (as Jason pointed
out to my off-line), so are cross-repository MOVEs in the case of
cross-repository bindings.  A client has no way to know beforehand
whether a cross-repository MOVE will succeed, but may want to attempt
one before performing a COPY/DELETE instead.

-brian
briank@xythos.com