Subject: FW: [Moderator Action] Re: Are you using lock discovery?

From: "Jim Whitehead" <[email-masked]>
Date: Tue, 26 Jun 2001 17:40:54 -0700

Oops, accidentally caught by the spam filter. I've added Joe's email to the
accept2 list.

- Jim

-----Original Message-----
From: Joachim Feise [mailto:[email-masked]]
Sent: Tuesday, June 26, 2001 4:30 PM
To: Jim Whitehead
Cc: WebDAV WG
Subject: [Moderator Action] Re: Are you using lock discovery?

Jim Whitehead wrote:
>
> Jason Crawford asks:
> > Do we have any clients out there that do lock discovery or are
> > dependent on
> > this property?
>
> As I recall, the DAV Explorer client <http://www.ics.uci.edu/~webdav/>
uses
> lock discovery. I believe it's smart enough to do lock discovery if a
> resource is locked, and DAV Explorer doesn't have the lock token. It then
> tries the lock token on the off chance the requesting principal actually
> owns the lock.
>
> Or maybe we just talked about doing this, and never implemented it. I
can't
> remember -- Joe?

You described the implementation accurately.

>
> > Do we have any that require LNR's?
>
> I don't believe DAV Explorer depends on LNRs in any way.

It doesn't.

-Joe

---

From: "Clemm, Geoff" <[email-masked]>
Date: Tue, 26 Jun 2001 21:37:39 -0400

I hope by "grabbing the lock token", you meant unlocking the resource
and asking for a new lock (and then, only after warning the user about
the risk of overwriting the value from another editor session that they
forgot about).  This at least gives you some protection from forgetting
about another session you had open (an attempt to update from that
earlier session will then fail because the lock token is no longer valid).

Cheers,
Geoff

-----Original Message-----
From: Jim Whitehead [mailto:[email-masked]]
Sent: Tuesday, June 26, 2001 7:23 PM
To: Jason Crawford
Cc: WebDAV WG; Joachim Feise
Subject: RE: Are you using lock discovery?

> <<
> As I recall, the DAV Explorer client
> <http://www.ics.uci.edu/~webdav/> uses
> The spec deprecates that kind of client behavior for the reason that two
> programs that don't know about each other might be logged on as the same
> person, right?

Not really -- an authoring program will at least know that it had to do lock
discovery to grab the lock token, and presumably would then query the user
for whether they want to grab the lock.

In the case of DAV Explorer, we felt that a user might want to undo a lock
taken out by themselves using another program as a way of either testing the
protocol (and applications), or undoing a lock after an app. had crashed.

- Jim

---

From: "Clemm, Geoff" <[email-masked]>
Date: Wed, 27 Jun 2001 13:51:42 -0400

I have to vigorously disagree with Jim's suggestion that it is 
ever reasonable behavior for a client to steal a lock without
first having a dialog with the user.  People work on multiple
machines, and with multiple clients on the same machine that
access the same resources (e.g. Word and the Windows Explorer).
It is just too easy to forget or not notice that you already
have a client open that is modifying a resource.  And if the
user does explicitly tell the client to go ahead and steal the
lock, it should do so by unlocking the resource, and obtaining
a new lock.  This ensures that if the original locking client is still
around, it will not overwrite the data you just uploaded.

Cheers,
Geoff

-----Original Message-----
From: Jim Whitehead [mailto:[email-masked]]
Sent: Wednesday, June 27, 2001 1:20 PM
To: WebDAV WG
Subject: RE: Are you using lock discovery?

> I'm sure Jim know this, but I'd just like to warn other client developers
> that servers are not obligated to expose the lock-token in the
> lock-discovery property.   Servers might chose not to expose the tokens so
> as to avoid the situation described in section 7.6.  Make sure
> your clients can handle a server not returning the lock token in the
lock-discovery
> property.

Well, actually, this did take me a bit by surprise. But, after re-reading
Section 13.8, Jason is right, we do allow servers to hold back some elements
of the lockdiscovery property. But, the stated rationale is access control,
not keeping clients from grabbing lock tokens.

It seems to me the root issue here is how much you trust users to remove
their own locks. For DAV Explorer, we felt the people using the tool would
likely either be doing server development, or setup of a WebDAV server. That
it why we added the protocol logging feature to the tool. While DAV Explorer
is useful enough to accomplish some day-to-day editing work, we didn't think
that would be its main use (we were somewhat surprised to see DAV Explorer
get bundled with the Merlin server:
http://www.abriasoft.com/products/product16.php :-). Since we felt our user
base would be fairly sophisticated, we were comfortable giving them the
ability to grab locks that they took out using another program (and no, I
don't think DAV Explorer prompts the user about this).  This makes it a
handy protocol exploration tool. If you want to know exactly how tool X
performs when a lock is yanked out from under it, you can use DAV Explorer
to unlock the resource.

For more mainstream *authoring* tools, I agree completely that, if the user
is granted the ability to grab a lock, they should be shown a dialog box
about the event.  As for tools like Goliath that give a filesystem-like
view, I think a good case can be made either way (prompting or no
prompting). Perhaps it should be configurable, or the dialog should have an
option to not be displayed in the future.

- Jim