W3C home > Mailing lists > Public > w3c-dist-auth@w3.org > October to December 1999

Re: why URL protection is not feasible when you version collectio ns

From: WJCarpenter <bill@carpenter.ORG>
Date: Wed, 27 Oct 1999 14:52:04 -0700
Message-ID: <4418-Wed27Oct1999145204-0700-bill@carpenter.ORG>
To: w3c-dist-auth@w3.org
gmc> And as for that user, as soon as they unlock the file, that
gmc> increasingly irritated co-worker who's been waiting for them to
gmc> *finally* release their ?*?!@*! lock so they can get their job
gmc> done, will move that file to the new place anyway, and the user
gmc> will have to deal with it (without even getting the friendly 302
gmc> to warn them!).

A lot of the discussion recently seems to have been assuming that this
carpet-from-under-you movement is being done by someone else (or the
same person) using a WebDAV MOVE.  That seems *incredibly* unlikely
and occasional to me.  Though I'm sure that could occur sometime, the
most likely scenario to me, it seems, is some Very Powerful
Administrator moving things around directly on the server (or in the
database or in the shoebox or whatever).  It's hard for me to imagine
a document repository where the only possible access mechanism is
WebDAV.

Even if the WebDAV server implementors do a complete and thorough job
of tying LOCKing in with whatever other tools the administrator has
available, it is the nature of administrative activity that there will
certainly be a way to instantly nuke any LOCKs that get in the way.
This is RFC-2518 compliant, and one presumes that clients will have to 
muddle through this.

If you have a reasonable administrator, you'll get an email along
these lines:  "Tonight we're reorganizing the /whatsit/thatsit tree,
in accordance with blah-blah-blah.  Be sure to check in anything you
have out before you go home tonight or be prepared to look for it in
the new place."
-- 
bill@carpenter.ORG   (WJCarpenter)           PGP
bill@bubblegum.net                    0x91865119
38 95 1B 69 C9 C6 3D 25  73 46 32 04 69 D6 ED F3
Received on Wednesday, 27 October 1999 17:53:17 GMT

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