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

From: Jason Crawford <[email-masked]>
Date: Sat, 8 Mar 2003 11:06:49 -0500

> What is (or was) open to discussion whether servers may want to support
>
> - multiple bindings
> - BIND live properties
> - BIND MOVE semantics
>
> without supporting UNBIND semantics (or actually without supporting
UNBIND
> semantics on the *last* binding to a collection). That's what we planned
to
> do in our server, and I think this behaviour should be allowed.
>
> Making the "new" behaviour explicit in UNBIND/REBIND instead of
DELETE/MOVE
> allows a server to support clients that are only RFC2518-aware as before,
> yet offers newer clients the ability to rely on the tightened semantics
(or
> reliably get the request failed if the semantics cannot be offered).
>
> Coming back to the new methods:
>
> REBIND/MOVE: I think everybody agrees that it would be a good if new
clients
> could request a resource MOVE that will leave all dead and live
properties
> intact. If we can't put that into RFC2518-MOVE, we'll need a new way of
> marshall the request. Do we have consensus here?
That seems valuable and I must have overlooked that view on it in the
previous
discussions.

> UNBIND/DELETE: I think there was some confusion here about why people did
> not like requiring DELETE to use UNBIND semantics. If a server *does*
> support multiple bindings, DELETEing one of many bindings indeed should
only
> remove that binding, and thus be atomic (does anybody disagree here?). I
> only have an issue to require this particular semantics for the *last*
> binding to a collection (in which case I'd prefer to use the old RFC2518
> DELETE semantics).
I know Julian knows this, but just in case others don't...  that
"last-binding" (from
outside the tree) check applies to all bindings in the subtree.

Julian,
   would you be willing to support both in your server.  If you think
clients prefer
the non-atomic delete on the final binding, you could implement that for
DELETE
and you'd still implement UNBIND atomicly?

The reason I ask is that if servers are going to implement these operations
only
one way, that limits the value of having two methods.  Clients will only
get the one way
that the server implements anyway (or they can buy a new server).  There is
little point
in a client implementor calling UNBIND if few servers will implement it
unless he knows
that his user wants only that behavior.  But unless he knows that, he has
to make DELETE
the default thing he calls.  A seperate UNBIND method becomes almost
pointless.
Whereas if server vendors implement each semantic and each semantic are
invokable
with a predictable method, the clients can specify what they want to
happen.

Anyway, that's why I ask what you (and other server vendors) would do with
your server
if the current proposal were passed.

J.

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

---

From: "Julian Reschke" <[email-masked]>
Date: Sat, 8 Mar 2003 19:00:04 +0100

> From: [email-masked]
> [mailto:[email-masked]]On Behalf Of Jason Crawford
> Sent: Saturday, March 08, 2003 5:07 PM
> To: Julian Reschke
> Cc: 'WebDAV'
> Subject: RE: Move and Delete (was: bind draft issues)
>
>
> ...
>
> Julian,
clients prefer
DELETE
> and you'd still implement UNBIND atomicly?

It's more a matter of server policy. I don't think we *want* to support the
atomic UNBIND functionality when deleting the last binding to a collection.
Thus our server might support UNBIND if and only if the binding being
removed is not the last one.

> ...

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

---

From: "Lisa Dusseault" <[email-masked]>
Date: Sat, 8 Mar 2003 11:07:21 -0800

I second what Jason said -- based on the lack of client support for
"propertybehavior" I'd like to see a couple client implementors say they
would implement a feature which would allow them to choose, on some
servers supporting atomic MOVE/DELETE, whether to force that behavior or
not.  

A light-weight approach is that since some servers will be atomic and
some won't, merely define some string in a header or body in response to
OPTIONS which says "I do atomic delete always" or "I don't always do
atomic delete".  Clients may or may not use that information, but at
least it's really easy for a server to advertise.

Lisa

---

From: "Julian Reschke" <[email-masked]>
Date: Sat, 8 Mar 2003 20:17:28 +0100

> [mailto:[email-masked]]On Behalf Of Lisa Dusseault
> Sent: Saturday, March 08, 2003 8:07 PM
> To: 'Jason Crawford'
> Cc: 'WebDAV'

We do.

> least it's really easy for a server to advertise.

I think this approach is too simple. Whether a MOVE will be atomic or not
may depend on source, destination and state of resources. That isn't
something I want to compute upon OPTIONS.

Julian