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

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

From: Brian Korver <briank@xythos.com>
Date: Fri, 7 Mar 2003 12:22:14 -0800
To: "'WebDAV'" <w3c-dist-auth@w3.org>
Message-Id: <7C2F822B-50DA-11D7-8A8F-000393751598@xythos.com>

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
Received on Friday, 7 March 2003 15:22:17 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 2 June 2009 18:44:03 GMT