RE: Bindings, Locks, and MOVE

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: w3c-dist-auth-request@w3.org
[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



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

Received on Wednesday, 15 September 1999 15:24:37 UTC