- From: <ccjason@us.ibm.com>
- Date: Fri, 17 Sep 1999 09:38:08 -0400
- To: "Geoffrey M. Clemm" <gclemm@tantalum.atria.com>
- cc: w3c-dist-auth@w3.org
------------------------------------------ Phone: 914-784-7569, ccjason@us.ibm.com "Geoffrey M. Clemm" <gclemm@tantalum.atria.com>@w3.org on 09/17/99 12:24:37 AM Sent by: w3c-dist-auth-request@w3.org To: w3c-dist-auth@w3.org 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>
Received on Friday, 17 September 1999 09:32:09 UTC