

RE: Bindings, Locks, and MOVE

From: Kevin Wiggen <wiggs@wiggenout.com>
Date: Wed, 15 Sep 1999 12:21:04 -0700
To: ccjason@us.ibm.com, "Slein, Judith A" <JSlein@crt.xerox.com>
Cc: w3c-dist-auth@w3.org, "'Geoffrey M. Clemm'" <gclemm@tantalum.atria.com>
Message-id: <LNBBKDGPNJMOJNOBHLLMIEHBCCAA.wiggs@wiggenout.com>

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


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


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

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.


-----Original Message-----
[mailto:w3c-dist-auth-request@w3.org]On Behalf Of ccjason@us.ibm.com
Sent: Wednesday, September 15, 1999 11:54 AM
To: Slein, Judith A
Cc: w3c-dist-auth@w3.org; 'Geoffrey M. Clemm'
Subject: RE: Bindings, Locks, and MOVE

lock doesn't address this case.

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

point we have:

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


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
resource than we started with, but it's a "copy", so we should be surprised
that means there's one more new resource in the world.  It's the same thing
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

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
the destination first, what we see isn't a change of state... but a change
resource at the destination.
Received on Wednesday, 15 September 1999 15:24:37 GMT
