Re: Bindings, Locks, and MOVE

   From: ccjason@us.ibm.com

   <jc/> Geoff, please check me if I'm wrong... but I think kevin is
   talking about COPY/MOVE'ing ***TO** the multiply bound resource, not
   from.  As currently written, the COPY/MOVE does a delete on the
   destination right up front... so the binding to a shared object is
   lost.  A PUT to either URI of the resource doesn't break their ability
   to share the resource.

<gmc>
Ooops!  Jason is completely right.  Sorry about the bandwidth wastage.
So I'd like to retract my earlier posting, and just agree with Kevin
that a COPY that preserves destination bindings is a useful operation
that is currently not provided by the protocol.

As a form of penance, I will propose a solution to this problem:

Add "DAV:merge" as a new potential value of the Overwrite header
when used with the COPY request.

The semantics COPY with Overwrite=DAV:merge is to "merge" the source
resource into the destination resource.  In case of non-collection
resources, this is just the equivalent of a PUT and a PROPPATCH into
the Destination.  In case of collection resources, it means
recursively PUT/PROPPATCH from the members of the source collection
into the corresponding member of the destination collection.
</gmc>

Any takers?

Cheers,
Geoff


   From: Kevin Wiggen <wiggs@wiggenout.com>

   <scenario-summary/>
   /~kwiggen/projectX/spec.html" and /~john/projectX/fgd/dfgdfg/dfgdg/spec.html
   are bindings to the same resource.

   <kw/> However if Kevin tries to simply COPY or MOVE
   /~kwiggen/projectX/spec_mine.html to /~kwiggen/projectX/spec.html, his
   BIND will be deleted, and Kevin and John will no longer be working on
   the same document.  All this and Kevin and John will probably not be
   any the wiser and blame each other for lack of updates :)

   <kw/> I believe this is a major FLAW with MOVE/COPY and it really
   comes out in BIND.  If the purpose is to have the ability for the same
   resource to exist in the namespace hierarchy (as the spec states in
   its introduction), then I would assume that BINDS last through
   MOVE/COPY just as they do through PUT and PROPPATCH.

   <kw/> The overwrite flag does not help in this situation.  If it is false,
   it means do not overwrite as before.  Overwrite to T means "Create me
   my own resource" in this case, and I believe that is not the intended
   behavior of the user.

Received on Thursday, 16 September 1999 12:24:35 UTC