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

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

> 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 14:07:23 UTC