RE: Simplifying RFC-2518 Locking: A non-proposal

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