W3C home > Mailing lists > Public > w3c-dist-auth@w3.org > January to March 2003

RE: RFC2518 issue: requiring ETags (Atlanta wg mtg)

From: Lisa Dusseault <lisa@xythos.com>
Date: Tue, 25 Feb 2003 17:07:10 -0800
To: "'Clemm, Geoff'" <gclemm@rational.com>, "'Webdav WG'" <w3c-dist-auth@w3c.org>
Message-ID: <016601c2dd33$63e1d3d0$f8cb90c6@xythoslap>

Geoff said:

"Just one comment on the statement "we've already discovered since
2518 was published that locks aren't the only tool required to
prevent lost updates".  I disagree ... locks are sufficient to
prevent lost updates.  If a client decides not to use the locking
protocol correctly (i.e. by updating a resource for which it does
not have a valid lock), then of course something additional is 
required, but for a client that uses the locking protocol properly,
locks are the only tool required to prevent lost updates."

This was back in November but I have so far failed to respond. 

Locks never did solve the "lost update" problem, precisely.  (Etags
alone are sufficient to prevent a user from overwriting another users
changes.) Locks solve the "aggravated user" problem, which is when I've
been working for six hours on a document, and when I try to save it to
the server the server tells me somebody else made changes and do I want
to overwrite those changes...

So I lock the file to prevent other people from making changes while I
work.  I get to reserve the file until I submit all my changes. I'm
never presented with a dialog saying "do you want to overwrite"...
Ideally, that is.

In reality, locks can be lost.  The most common situation is probably
when the client goes offline accidentally during an editing session.
Users and client applications have no control over wireless, routers,
power -- failures that can prevent the client from renewing a lock.

So let's say you've lost your lock.  The user has been editing while the
lock existed, and they already made changes. When the client manages to
reconnect to try to save, the lock is gone.  Well, there are two
situations:
 (1) The file changed while it was unlocked.  That sucks, there's no
choice but to prompt the user to find out what they want to do.
 (2) The file did *not* change while it was unlocked.  Cool. Without
bothering the user with difficult and annoying questions, the client can
simply relock the file and save changes. 

Since (2) is much more common than one, and much more pleasant, the
client would like to know when (2) is the case.  Etags would solve this.
That's why I claimed that locks alone did not entirely solve the
lost-update problem.

Lisa
Received on Tuesday, 25 February 2003 20:07:12 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 2 June 2009 18:44:02 GMT