- From: Edgar Schwarz <Edgar.Schwarz@de.bosch.com>
- Date: 1999年10月13日 10:52:49 +0200 (MESZ)
- To: w3c-dist-auth@w3.org
- Message-ID: <Pine.GHP.4.05.9910130955550.15170-100000@hpmx15.bk.bosch.de>
Hello, I'm back again after being in hospital for some weeks. It seems there was a hot debate over my proposal which is over now but I still would like to add my 0ドル.02. Thu, 7 Oct 1999 bill@carpenter.ORG wrote: > gmc> My non-proposal is as follows: Modify RFC-2518 to: > gmc> - remove depth locks, shared locks, and lock null resources > gmc> - add a Target-Selector header for reliable access to a locked resource > gmc> - make simple single resource locking mandantory. > > "Stop it ... You're getting me *hot*! :-)" I think the cut is cool :-). You wanted a simpler standard Yaron, so how's this ? BTW, I'm trying to write a client for Oberon (http://www.oberon.ethz.ch) so my decisions aren't important for many people. Nevertheless, FYI I don't plan to spend time for the arcane features Geoff wants to drop (if I can avoid it). I don't think they are worth my time. Then I have a question. Why is a DELETE allowed ? Shouldn't be in my opinion (7.1 Methods Restricted by Write locks). Perhaps this should be clarified so that a DELETE for the locked binding is forbidden but an DELETE on other bindings is allowed. Here is a difference between DELETE and PUT,POST,... Now some global stuff :-) - I think that locks are here to stay in RFC2518, they are on the resource and move with the resource. - Now as a server administrator I absolutely want to be able to move locked resoures if it is necessary. - OTOH as a client I won't tolerate disappearing resources I have locked. - Therefore my proposal that an access to a moved resource (changed binding) with URL and locktoken must give me the new URL (not the resource). So the client can tell his user: Look this stuff has been moved ! And after it is accessed one time the server can drop his note about the move. The client now knows where it has gone to. So I also see no problems with the following scenarios. - Multiple moves: the client only wants to know where it is now. He isn't interested in intermediate bindings. This also should work with inter server moves. A server only has to remember the URL on the other server it is moved to. If there are more moves it's the responsibility of the receiving server to remember. Now Yarons problems: - Being at work, taking a lock: If you want to work at home then you obviously have to remember the lock. Then you can access it at home without any problem with lock and old URL. - Editing HTML in Word, validiating in Netscape: If somebody moves the resource inbetween Netscape won't find it, oops ! You go back to Word and e.g. try to reload the document. Word tells you that it has moved to another location. Then you just have to adapt the URL in Netscape. Not so complex I still think. Cheers, Edgar -- Edgar.Schwarz@de.bosch.com ON/EUE1, 07191/13-3382 Niklaus Wirth: Privat kann jeder soviel C programmieren oder Videos ansehen wie er mag. Albert Einstein: Mach es so einfach wie moeglich, aber nicht einfacher.
Received on Wednesday, 13 October 1999 04:53:58 UTC