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

A few years ago, we did discuss introducing new methods
(I prefer UNBIND/REBIND, rather than UNBIND/RENAME) so
that a client can specify when it requires atomic behavior
rather than "best effort" behavior.  Eventually, we concluded
that any server that supported multiple bindings to
a resource should also be capable of supporting atomic
DELETE/MOVE behavior, and since no user would want non-atomic
behavior if they could get atomic behavior, it is simplest just
to associate the atomic behavior with the support of
the BIND operation.

But since we have folks who insist their users want non-atomic
behavior (even when the server could support atomic behavior!),
I'm willing to go back to the UNBIND/REBIND approach. But I'd
like to at least provide guidance to implementors stating that
DELETE/MOVE *should* be implemented atomically as UNBIND/REBIND
if the server is capable of doing so.

I've posted a revised version of the binding draft to the
binding web site.  Let me know what you think.
<http://www.webdav.org/bind/draft-ietf-webdav-bind-01.2.htm>

Cheers,
Geoff

-----Original Message-----
From: Julian Reschke [mailto:julian.reschke@gmx.de]

> From: Brian Korver
>
> On Wednesday, March 5, 2003, at 01:48  PM, Brian Korver wrote:

> > On Wednesday, March 5, 2003, at 12:34  PM, Julian Reschke wrote:
> [snip]

> >> Now I *do* agree that in many cases clients will actually *want* the
> >> "weak"
> >> MOVE. So maybe we should consider supporting both (either by a new
> >> method,
> >> or by adding parameters to MOVE).
> >
>
> Were you thinking that this header (say "Atomic-Operation:") would be
> used for only MOVE, or for all of the relevant operations (COPY,
> DELETE, etc.)?

Actually, I'd really prefer not to define additional headers.

Thinking of it, we *also* can't agree on the right DELETE semantics (see
separate discussion). So one way to address this would be to leave DELETE
and MOVE as they are, and to add

- UNBIND (that really really really removes bindings, thus has the DELETE
semantics currently specified by the BIND draft) and
- RENAME (which would be a true MOVE that would fail when the server can't
implement it as internal namespace operation).

This would make discovery of the new functionality much easier.

Received on Friday, 7 March 2003 08:55:37 UTC