Subject: RE: Bindings, Locks, and MOVE

From: [email-masked]
Date: Wed, 15 Sep 1999 14:54:08 -0400

<js>
Actually I was confused by thinking that a write lock would prevent a COPY
with Destination being the locked resource.  (So I thought that the COPY
step wouldn't be allowed to happen.)  But I see that the definition of write
lock doesn't address this case.

I do have trouble following your description of the fixup stage, though.  I
take it you don't think we face the awkward situation Kevin described, where
there end up being 2 resources where there used to be only one.  But how do
you avoid this?

Before the MOVE we have:

/a/b.html   /x/y.html         /c/d.html
    \         /                   |
     \       /                    |
      \     /                     |
         R                        S

and user1 has a lock on R through /a/b.html

Now user2 attempts to MOVE /c/d.html to /x/y.html.  First the binding y.html
is removed from collection /x/.  Then S is duplicated, say to S' and a new
binding y.html is created in /x/ to S'.  That's the COPY step.  At this
point we have:

/a/b.html     /x/y.html      /c/d.html
   |             |              |
   |             |              |
   R             S'             S

The DELETE step is to remove the binding d.html from /c/.  It doesn't look
as if there needs to be any fixup, but we do have the awkward result that we
now have 2 resources R and S' where there used to be just R.
</js>

<jlc>
I have to agree that I couldn't quite understand what GC meant by "fixup"
since it seemed none was necessary.

I also don't understand what you are saying about extra resources.

We began with R and S.   In a COPY we end with R, S, and S'.    That's one more
resource than we started with, but it's a "copy", so we should be surprised if
that means there's one more new resource in the world.  It's the same thing that
we see when we go to a xerox/copy (:-))  machine.  We walk go there with one
copy of a document and walk away with two.

As for the MOVE, we start with two resources and end with two.  No surprise once
again.

The only surprise might be that some folks might intuitively think of a
MOVE/COPY as replacing of the destination's state, but since we say it deletes
the destination first, what we see isn't a change of state... but a change of
resource at the destination.
</jlc>

---

From: Kevin Wiggen <[email-masked]>
Date: Wed, 15 Sep 1999 12:21:04 -0700

I knew that the "Delete/Make New Resource" vrs "Merge" would come to haunt
me one day.

Kevin and John are working on a project.  John creates a file

/~john/projectX/fgd/dfgdfg/dfgdg/spec.html

Kevin thinks john is long-winded and simply creates a bind to the resource

/~kwiggen/projectX/spec.html

Now they both can view/update the file, as they are working together.

If Kevin does a PUT to his Bind, it will replace the file and John will see
the update.

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

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.

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.

Kevin

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]]On Behalf Of [email-masked]
Sent: Wednesday, September 15, 1999 11:54 AM
To: Slein, Judith A
Cc: [email-masked]; 'Geoffrey M. Clemm'
Subject: RE: Bindings, Locks, and MOVE

<js>

Before the MOVE we have:

<jlc>

We began with R and S.   In a COPY we end with R, S, and S'.    That's one
more
resource than we started with, but it's a "copy", so we should be surprised
if
that means there's one more new resource in the world.  It's the same thing
that
we see when we go to a xerox/copy (:-))  machine.  We walk go there with one
copy of a document and walk away with two.

As for the MOVE, we start with two resources and end with two.  No surprise
once
again.

The only surprise might be that some folks might intuitively think of a
MOVE/COPY as replacing of the destination's state, but since we say it
deletes
the destination first, what we see isn't a change of state... but a change
of
resource at the destination.
</jlc>

---

From: "Geoffrey M. Clemm" <[email-masked]>
Date: Wed, 15 Sep 1999 17:10:16 -0400

From: [email-masked]

   <js/>

   <jlc/>

<gmc/> This thread was one where Judy was concerned that our
definition of MOVE was incompatible with being "logically equivalent
to COPY/fixup/DELETE".  So although an extra resource is what you
would expect (rightly so) after a COPY, an extra resource is *not*
what you would expect after a MOVE.  In an earlier posting, I pointed
out that the "fixup step" could be used to get rid of the extra resource.
But to emphasize, defining MOVE as COPY/fixup/DELETE is *bad* (as in
"bad dog, don't mess the carpet" :-)

   <jlc/> As for the MOVE, we start with two resources and end with two.
   No surprise once again.

<gmc/> But without a "fixup", if you just do COPY/DELETE to implement
your MOVE, Judy's example would end up with three
resources following the MOVE, rather than two, thus her concern.

Cheers,
Geoff

---

From: "Geoffrey M. Clemm" <[email-masked]>
Date: Wed, 15 Sep 1999 17:45:38 -0400

From: Kevin Wiggen <[email-masked]>

<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