- From: -=jack=- <jack@twaxx.twaxx.com>
- Date: Mon, 7 Jul 1997 14:32:02 -0700
- To: "'Judith Slein'" <slein@wrc.xerox.com>, Dylan Barrell <dbarrell@opentext.ch>
- Cc: jack@twaxx.com, "jradoff@novalink.com" <jradoff@novalink.com>, "w3c-dist-auth@w3.org" <w3c-dist-auth@w3.org>
I think it should be up-to the implementation whether the write lock prevents people from reading a resource. I can definitely see the requirements for both types of locks (although I think that the type which allows reading is more valid in a Web environment) but I think it overkill to require provision of both ---------------- I think it would be ok to allow the implementation and those doing it to decide whether or not they want to support either allowing the reading of resources which are write-locked, or to prevent people from reading a resource when it's write-locked, but I think we should decide whether or not we'll choose one or the other of these definitions, or support both. Perhaps I'm mistaken, but it's my feeling that part of what we're trying to do is to present the basic landscape of this technological area to the community at large, and to make reasonable judgments about how to negotiate this landscape... if this is true, it's my feeling that we should clearly examine the issue and make a decision. Either you can read write locked resources, or you can't, or there's infrastructure to support both, which may then be applied as necessary and/or desired. For what it's worth, I'm of the feeling that it's perhaps not necessary to prevent folks from reading a resource simply because a new revision is currently being created as there's usually no reason to be concerned or interested until that new revision is available, although I can imagine cases in which folks might not want to read a document when they know a new version is being created, and in this case, they might want to wait. It would seem that we need to decide how important this is. It it's very important that write locks be able to prevent the accessing of a resource, then we should probably support it. If it's also determined that this can be a nuisance (and it's my contention that it *will* be a nuisance if *all* write locks prevent the read access of the particular resource) then when it's not necessary in a given case, we should probably allow it to be optional to facilitate the proper treatment of resources, or in other words, we should probably support both. Are there critical cases in which preventing read access for resources which are currently write locked is critically important? If so, what are these cases? Is there compelling evidence to state that ALL write locks should prevent any read access? If there's need, then we should probably support both policies, but we should be fairly careful to make sure there really is reason to support both... any comments? -=jack=- (This text composed by voice) --
Received on Monday, 7 July 1997 17:33:34 UTC