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

From: Jason Crawford <[email-masked]>
Date: Tue, 4 Mar 2003 19:02:19 -0500

On Tuesday, 03/04/2003 at 04:47 CET, "Julian Reschke"
<[email-masked]> wrote:
> > Saying that it doesn't support atomic deletes doesn't make sense to
> > me.  The concept doesn't exist.   The binding spec's  DELETE command is
> > asking that only one thing be done.   If you can't do that one thing
you
> > need
>
> And that's why we're discussing this right now. The BIND spec requires a
> very specific DELETE behaviour, and some people do not seem to find that
> acceptable. Therefore the need to come to a consensus.

I've only heard that servers are forced in to this behavior, not that bind
aware
clients actually want this behavior.   I'm arguing that servers can support
this at the
WebDAV level.  And if they can't they need to reject the DELETE request,
reject
BIND's to collections, or not claim that they are supporting BIND
functionality.

> Can you define how I can delete the binding a (a being a collection)
without
> also deleting the binding a/b (when b is present in a)?

See the rest of my posting.  Plus the posting I just made.  Plus what I say
below.

> > I would hope it's possible though and that you wouldn't have to reject
the
> > request. Even in a file system based server, I'd hope that the server
> could
> > simply unmap the collection and then in the background do the
delete/move
> > of the whole tree incrementally if that were appropriate.
>
> But what if this simply is not what the system *should* do?

I did say that it can happen in the background.  It doesn't have to.  It
can be
done in the foreground.

But no one has argued that they want partial results appearing as a result
of a DELETE
in the presence of bindings.  What they have argued is that that servers
are forced to leave
partial results.  I have shown that in the situations mentioned, they are
not forced to leave
partial results.

But doing what I suggest is not the only acceptable approach.  Server
implementations can
claim not to support bindings,
reject BIND requests to collections, or reject DELETE requests that they
aren't sure they can
complete.   But they can't return partial deletion in the presences of
multiple bindings.

> > But if it can't, IMO it needs to reject the request.
>
> It may not be able to reject the request until after it has started
removing
> resources. There's a reason why DELETE isn't atomic in RFC2518.

See the rest of my posting.  You probably can detect if you will not be
able to complete
the operation.   If the MOVE completes, you have completed the request.  If
it
fails, you have not.  This does not leave partial results.   What you will
still need
to do is clean up symbolic references.in to the tree.  This might be
possible to
do in a simple remapping request or you can do it iteratively... or both
ways. This
can be done in a way that makes it unnecessary to have to return partial
results.
Finally... the server probably will want to reclaim (perhaps only in the
absense of
versioning) inaccessable resources.   But that problem doesn't change the
semantics of the WebDAV operation.  If it needs to do that, it can do that
in the
foreground before completion (as it would have had to do anyway) or in the
background, but it doesn't effect what the UNBIND/DELETE method should
return
to the client.

------------------------------------------
Phone: 914-784-7569,   [email-masked]
I do not check [email-masked]

---

From: "Julian Reschke" <[email-masked]>
Date: Wed, 5 Mar 2003 01:27:36 +0100

> From: Jason Crawford [mailto:[email-masked]]
> Sent: Wednesday, March 05, 2003 1:02 AM
> To: Julian Reschke
> Cc: Clemm, Geoff; Julian Reschke WebDAV
> Subject: RE: Move and Delete (was: bind draft issues)
>
>
>
>
>
aware
> clients actually want this behavior.   I'm arguing that servers  can
support this at the
> WebDAV level.  And if they can't they need to reject the DELETE request
reject
> BIND's to collections, or not claim that they are supporting BIND

a) what if they want to just implement RFC2518's DELETE?

b) how do I not claim to support BIND functionality, when indeed I *do*
implement the BIND live properties and the BIND method?

> ...
the
could
delete/move
can be
> done in the foreground.

Yes.

However: this was true for RFC2518's DELETE, yet after very long discussion
the spec ended up with a non-atomic DELETE. I think this was correct (if
only for the reason that an atomic delete on a large namespace partition can
generate a transaction that's simply too big to handle properly).

It seems that this is an attempt to "fix" RFC2518's DELETE through the
backdoor. If this is the case, this should be made clear so that everybody
is aware of that.

of a DELETE
are forced to leave

I do.

not forced to leave
implementations can
aren't sure they can
multiple bindings.

Again, the issue is NOT a DELETE in the presence of *multiple* bindings to a
collection. The issue is a DELETE to a collection through it's only binding,
which RFC2518 allows to be non-atomic, while the BIND draft requires it to
be atomic. I think that's inacceptable.

removing
able to complete
> the operation.   If the MOVE completes, you have completed the
> request.  If it

MOVE is different because it is just a namespace operation. DELETE may
(may!) also destroy resources.

still need
possible to
ways. This
results.
> absense of versioning) inaccessable resources.   But that problem doesn't
change the
in the
return
> to the client.

So again: why is RFC2518's DELETE non-atomic? (I guess the answer is in the
WebDAV Book Of Why).

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