Re: Bindings, Locks, and MOVE

   From: ccjason@us.ibm.com

<context/> This is a discussion about a proposed
COPY/Overwrite=merge operation, where X->Y means a copy of X to Y,
and where C is a collection and NC is not a collection.

   <gmc>
   NC->NC is a combined PUT/PROPPATCH.  All bindings to the destination
   continue to be valid.

   C->NC replaces NC with a copy of C.  Any bindings to NC are now bindings
   to the copy of C.  If the server cannot do this rebinding, it must fail
   the COPY request.

   NC->C replaces C with a copy of NC.  Any bindings to C are now bindings
   to the copy of NC.  If the server cannot do this rebinding, it must fail
   the COPY request.

   C->C Recursively perform the merge MOVE from every member of the source
   collection to the corresponding member of the destination collection.
   </gmc>

   <jlc>
   Note: there might be a client-side need for a version of this that isn't
   destructive.  For example, what you recommend for NC->C can end up knocking
   a lot of resources out of the URI space.  If the client is a human, she
   may not have realized that she was doing that... and may in fact not realize
   this until later.
   </jlc>

<gmc/> The challenge is to define "non-destructive" in a way that is
consistent and correct (i.e. does what the user wants).  I predict
that the only way to do a non-destructive COPY/merge is to have the
client use the protocol to iterate through the source and destination
resources, asking the user what to do in cases where something is
being overwritten.  This dialog is not something we can capture in a
single HTTP method.

<gmc/> I'd be happy to say that C->NC and NC->C just fail, thereby
forcing the client to handle this case explicitly.

Cheers,
Geoff

Received on Friday, 17 September 1999 10:23:29 UTC