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

> > Right.  To claim BIND spec support, you have enhance the implementation
to
> > support *this*  2518 compliant approach.... or to avoid a situations
where
> > bind spec
> > violations would happen.   It's not unreasonable to expect one to have
to
> > add code
> > in order to support a new feature like multiple-bindings.
>
> Actually, I'd have to remove code.
>
> The issue isn't that the server can't *technically* do this -- it's that
the
> this semantics isn't compatible with the existing DELETE semantics of our
> system. Just removing the collection binding without checking that all
> internal members may be deleted as well simply is *not* an option.

Okay, so I'll stop talking about symbolic links :-)

If there are multiple bindings to a collection and a WebDAV request asks
you do DELETE one of them, will your server end up deleting all the
descenent bindings also... or just the one requested?

Is it not possible to freeze the system while your system checks this?
Perhaps in a way similar to the way the Win32 has to before it allows
a MOVE.  In its case, is seems to find it acceptable to delay while
it's checking this.  It can cause a delay of a few seconds, but apparently
the folks that implemented that found it acceptable.



> So basically we have the choice between
>
> - supporting multiple bindings, but not the BIND method described in the
> draft, or
> - simply ignore this requirement.

Or I suppose, "not allow multiple bindings to collections?"

> I'd rather have a spec that I can implement without having to break a
> specific requirement (in particular if i'm not convinced it adds value to
my
> use case).

The other day I ran in to this in a non-WebDAV situation.  I tried to move
a huge
directory.  I found it frustrating to find that it was moving the files one
at a time and
ran in to a problem and left me with two partial trees.  (This was across
file systems.)
I would have been similarly, although less problematically, frustrated if
it had been
a delete request.

------------------------------------------
Phone: 914-784-7569,   ccjason@us.ibm.com
I do not check nn621779@smallcue.com

Received on Tuesday, 4 March 2003 19:37:38 UTC