Subject: RE: DELETE leaving a lock-null resource; was LOCK Scenarios

From: "Yaron Goland (Exchange)" <[email-masked]>
Date: Sat, 23 Oct 1999 14:45:33 -0700

> Using the updated proposal where a process gets back a 302 when it
> tries to access a locked resource that has moved, word will have to
> update its path to the document the next time it accesses it for read
> or write.  When it does so, the user will know to look
> at the new place in a different process.
> 
> Also note that a user is already used to some difference 
> between what is
> seen in the process that has the lock and another process 
> that does not.
> In particular, any changes that have not yet been saved will 
> only appear
> in the process with the lock.

How long do you expect the original resource to remember the forwarding
information? So if you move foo/bar to foo/baz and someone else creates a
new resource at foo/bar then the forwarding from foo/bar to foo/baz will be
destroyed. These are file systems, they don't have long memories.

Also, how do you think the UI in Hiro's word processor is going to tell him
about the name change? "Dear Hiro, someone decided to move your file for
you, it now lives at the following name." I can't ship that product, my
users would revolt.

> Probably somebody who had a good reason do so (perhaps fixing a bad
> copyright statement in her document).  In either case, there is no
> lost update problem, since she has no pending updates to the document
> (except for those only in her head, which we can't take responsibility
> for :-).

The only problem is that her document has mysteriously disappeared, even
though she locked it. Admittedly this can happen anyway if the admin
overrides her lock but that is a very rare circumstance and enough of a
disaster that the admin would be expected to send e-mail out to those
affected. The same would not be true here. If Joe comes along and moves the
entire directory and isn't aware that Irit had a locked file he would never
know he should tell Irit. So when Irit comes back her file is gone and she
has no idea what has happened. Even if Joe knew, it wouldn't be sufficient.
Irit wants her stuff staying where it is, that is why she took out the lock.
You seem to believe that locks are just there to protect content. That
simply isn't true. Locks are there to control the name for it is the name
which gives access to everything. By controlling the name you control where
the name can be moved as well as who can access the content pointed to by
the name. Locks are more about names then they are about content.

> 
> My generic response to this situation: locks are great for preventing
> lost updates.  You LOCK,GET,edit,PUT,UNLOCK.  The faster you 
> get in and
> out with your lock, the better.  If you want to leave the world locked
> up so that your job is easier, you're ignoring the needs of all the
> other people that need to get their jobs done.
> 

In our experience the over whelming majority of documents are one user at a
time. That is, one user edits and then hands over control to another user.
Locks prevent control from being transferred prematurely. They also prevent
unwanted changes to shared namespaces. While documents are often single
user, namespaces are often shared. 

Widespread use of collaborative editing is only now starting and is in its
most infant stages. For a very long time most documents will be used by one
and only one person and suffer the problems described in the previous
paragraph. In fact, according to our studies, the #1 mechanism used to
collaborate on a document is e-mail. Copies get sent around and someone acts
as a redactor.

> With the speed of development and deployment being forced by 
> "internet time",
> I believe the days of locking up the world to get long-term 
> stability are over.
> 

I don't know what is in the future, only what is in the present. WebDAV has
to be able to do what we can already do today before it can move into
uncharted territory. The locking proposal prevents scenarios that work today
and thus prevents WebDAV's adoption by file system based programs that exist
today.

> Cheers,
> Geoff

The bottom line is the question of the relationship of names to locks. In
the file system world a name is the single most powerful piece of
information one has. The name is used to retrieve, to change, to control.
One of locking's most critical tasks is to provide for control over that
name. That is why WebDAV causes names to be locked along with content. This
wasn't an accident, it was a conscious choice based on experience shipping
editing systems that work against file systems.

Until the whole world moves over to powerful versioning systems we will have
to deal with file systems and in file systems, file names are king. Thus my
users MUST be able to pin down a name, own it and totally control it.

So long as there are file systems locks MUST control names.

			Yaron

---

From: "Geoffrey M. Clemm" <[email-masked]>
Date: Sat, 23 Oct 1999 20:11:22 -0400

From: "Yaron Goland (Exchange)" <[email-masked]>

   information?

In an implementation, it often isn't the resource that is remembering
the forwarding information, but rather some locking authority.  This is
true for many WebDAV implementations (although certainly not all).
The locking authority must maintain any forwarding information
for the lifetime of the lock.

   So if you move foo/bar to foo/baz and someone else creates a
   new resource at foo/bar then the forwarding from foo/bar to foo/baz will be
   destroyed. These are file systems, they don't have long memories.

If an implementation cannot maintain forwarding information, then it must
fail the move (with a "locked" status).

   Also, how do you think the UI in Hiro's word processor is going to tell him
   about the name change? "Dear Hiro, someone decided to move your file for
   you, it now lives at the following name."   I can't ship that product,
   my users would revolt.

If Hiro's word processor is using HTTP (the premise of WebDAV), it had better
be prepared to handle a 302.

   know he should tell Irit.

The lock is there, and Joe could easily notify all the lock holders (assuming
the locks hold principal information, as is recommended).  In fact, if he
had a good client, it could largely automate the notification process.

   So when Irit comes back her file is gone and she
   has no idea what has happened. Even if Joe knew, it wouldn't be sufficient.
   Irit wants her stuff staying where it is, that is why she took out the lock.

And I want to put red lights on all cross-roads of all the intersections
on my way to work (:-).  But I'm not allowed to do that because it interferes
with everybody else's commute.  Just a silly analogy, but not too
far off the mark, I believe.

I think we agree that locks are there to prevent the lost update
problem (i.e. protecting content).  It is an interesting question as
to whether they are appropriate for preventing other problems, and if
so, how they are best used to do so.  I believe that locks are useful
for keeping a handle on where a locked resource is located, but that a
server should be able to allow the move and return a 302, if it wants
to maximize parallel work.  A server can also just fail a moves if it
cannot track the movement of a locked resource.

Yes, it is the shared nature of namespaces that causes me to resist
requiring anything like a "namespace lock".  To say that a server can
do such a lock if that's the best it can to, then that's fine.  But
to say that all servers must act that way leaves out a useful
alternative, namely, using 302's to let a client know the new location
of their locked resource.  Since a web client needs to know
how to deal with 302's anyway, I believe there is little or no
additional cost to clients.

Cheers,
Geoff