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

Re: Can you move a locked file?

From: Greg Stein <gstein@lyra.org>
Date: Tue, 26 Oct 1999 15:38:31 -0700 (PDT)
To: w3c-dist-auth@w3.org
Message-ID: <Pine.LNX.4.10.9910261532320.25216-100000@nebula.lyra.org>
On Tue, 26 Oct 1999, John Stracke wrote:
> "Yaron Goland (Exchange)" wrote:
> > My user's explicit goal is to prevent anyone, anywhere from have any ability
> > to manipulate their "private data worlds" in anyway.
> Uh...isn't that what access control is for?

I don't think so. Access control is long-term, locks are

I totally agree with Yaron here: if I'm editing a document (with a lock),
then it sure as hell better not move on me. That is just annoying and

This whole business about the server retaining redirects after a move of a
locked resource seems really and arbitrarily complex. Why support
something like that? Just say a server MUST refuse a move of a locked
resource rather than "well, it might or it might not, but you really won't
know unless you try."

And if this nonsense does go thru as a "consensus change" to the move/lock
behavior, then the default should be to refuse the move. There was a
suggestion that an app should set a flag to state that it can't support
locked resources that may move -- that's backwards since the current
behavior is "I lock it and it stays there until I unlock it." In other
words, an app should say "I can support you [the server] moving this
locked resource on me and sending me a 301 response."
(I still don't like it though because of the additional complexity on the
client, which people seem to be ignoring, much to Yaron's dismay; who on
this list is actually writing client software/tools/apps?)

Personally, I'll refuse the darn move. I'm not going to start recording
all these redirects on the server.


Greg Stein, http://www.lyra.org/
Received on Tuesday, 26 October 1999 18:37:39 UTC

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