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

> 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,   ccjason@us.ibm.com
I do not check nn621779@smallcue.com

Received on Saturday, 8 March 2003 11:12:16 UTC