W3C home > Mailing lists > Public > w3c-dist-auth@w3.org > April to June 2001

RE: lock-discovery property without a lock-token

From: Jason Crawford <ccjason@us.ibm.com>
Date: Wed, 27 Jun 2001 15:27:23 -0400
To: "Jim Whitehead" <ejw@cse.ucsc.edu>
Cc: "WebDAV WG" <w3c-dist-auth@w3.org>
Message-ID: <OF1ABC446E.33BAFA43-ON85256A78.0066A860@pok.ibm.com>

It seems to me the root issue here is how much you trust users to remove
their own locks.
I agree it's trust... users and client tools... be it to remove or replace
or reuse.

 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).
As an exploration tool I'd guess it probably should be able to do
*anything*.  :-)  But of course I'd think it should ask the user before it
takes discretionary action.  Knowing something was locked with a lock that
you didn't have seems like an important part of exploring.   So does
controling what's done...

   (Cancel) (Reuse lock)  (Replace lock)

  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.
I guess configurable is okay... but it probably should not be made easy for
an ordinary user to avoid being prompted.

It doesn't sound like Merlin's customers would be using DAVExplorer in the
exploratory way that DAVExplorer was intended to be used.  It sounds like
DAVExplorer could get them in trouble.

Received on Wednesday, 27 June 2001 15:31:21 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 15:01:23 UTC