Subject: Re: Bindings, Locks, and MOVE

From: [email-masked]
Date: Fri, 17 Sep 1999 09:38:08 -0400

------------------------------------------
Phone: 914-784-7569,   [email-masked]

"Geoffrey M. Clemm" <[email-masked]>@w3.org on 09/17/99 12:24:37 AM

Sent by:  [email-masked]

To:   [email-masked]
cc:
Subject:  Re: Bindings, Locks, and MOVE

   <jlc>

    S\ Dest
    r \
    c  \
        \     empty      |     non-Coll     |   Collection
         +---------------+------------------+----------------
         |NC->E          |NC->NC            |NC->C
   non   |               |                  |
   Coll  |   copy it     |     ?replace?    |       ?
         |               | (bind new copy?) |
        -+---------------+------------------+----------------
         |C->E           |C->NC             |C->C
   Coll  |   copy it     |         ?        |   copy members
         |   & members   |                  |     only

   </jlc>

  <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>

---

From: "Geoffrey M. Clemm" <[email-masked]>
Date: Fri, 17 Sep 1999 10:23:26 -0400

From: [email-masked]

<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>

   <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