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

> From: Jason Crawford [mailto:nn683849@smallcue.com]
> 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)
>
>
>
>
>
> On Tuesday, 03/04/2003 at 04:47 CET, "Julian Reschke"
> <nnjulian.reschke___at___gmx.de@smallcue.com> 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.

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?

> ...
> > > 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.

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.

> 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

I do.

> 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.

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.

> > > 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

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

> 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.

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

Received on Tuesday, 4 March 2003 19:28:11 UTC