- From: <ccjason@us.ibm.com>
- Date: Thu, 9 Sep 1999 22:37:51 -0400
- To: Edgar Schwarz <Edgar.Schwarz@de.bosch.com>, w3c-dist-auth@w3.org
Edgar, <gmc> Since the server needs to deal with this in case the client just neglects to remove the lock, and if having another client MOVE your locked resource is a rare occurrence (which I believe it is), then this does not seem to be especially problematical. </gmc> <edgar> Would it be possible to say: If a locked resource is moved the server SHOULD create a indirect reference resource which should exist for some sensible time. Yes I know, it's complicating the server :-) I imagine the above happening perhaps when somebody is reorganizing a directory structure and deep in the collections there are some locked resources. So the lock owner at least has a decent chance to find out where his resource has gone to. </edgar> <jlc> I believe you're proposing an alternative to protecting a lock URI... I don't think the server can create the indirect reference *during* the MOVE since (1) The now null resource URI may not have a parent after the move if the moved resource was a grandfather collection above. I think we require that even indirect resource have a parent. (2) The client that requested the MOVE might not be the owner of the lock. So telling the mover, doesn't really help the owner of the lock. I assume the owner of the lock is the entity most interested in knowing it moved. A similar approach to what you've suggested might be to provide a URI at the time the lock is created. I know that Geoff has one argument against it lined up already. :-) I still think it's worth discussing though. </jlc>
Received on Thursday, 9 September 1999 22:30:28 UTC