Re: Bindings, Locks, and MOVE

   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/> If Kevin does a PUT to his URL
  it will replace the file and John will see the update.

<gmc/> I'd probably use the word "update" rather than "replace",
since replace might be interpreted as saying that a new resource
created, whereas PUT just updates the state of the 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 :)

<gmc/> With the proposed advanced collection definition of MOVE, a MOVE
will *preserve* the bindings, while a COPY will not.

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

<gmc/> MOVE preserves bindings, but COPY does not (it creates new
resources).  Both semantics are important, which is why we have two
methods.

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

I agree that the Overwrite header should have nothing to do with
whether or not bindings are preserved.  In general though, Overwrite=T
does not mean "create my own resource", but rather "delete whatever
is currently there".

Cheers,
Geoff

Received on Wednesday, 15 September 1999 17:45:39 UTC