Re: Simplifying RFC-2518 Locking: A proposal

Geoffrey M. Clemm wrote:
> 

> I was wondering the same thing.  It seems like a fairly easy thing to
> compute.  If somebody tries to "MOVE" the resource outside of the
> resources you control, you can just fail the MOVE.  Otherwise, when
> someone comes at you with a URL and a Lock-Token header, just look the
> pair up in your table, and perform the request on that resource.
> 
>    It sounds like the server would
>    need to maintain a   lock + URI  ->  new URI mapping or something
>    like that.
> 
> lock + URI -> resource.  No need for the server to indirect through
> another URI mapping ... that would just make things hard.  The nice
> thing about being a server is that you have real resource handles
> and *don't* have to indirect through URI's.
I would vote for a lock + URI  ->  new URI mapping. More below.


>    i1) I suspect Geoff didn't mean it, but I think he said (by using the
>    word "identify") that the server "tells" the client where the resource
>    has moved to.  (If this is not what Geoff meant... skip to (i2).)
> 
> You are correct, that's not what I meant (:-).  By "identify", I mean
> the server figures out what the locked resource was, and applies the
> method to that resource.  Clients are not involved at all, so I'll
> skip to i2 ...
My idea was that the server will tell the client in this case just the
new URI. Then he can forget the mapping because the client now knows
the new URI and can reaccess it. Also the client can signal his user
that the
resource has moved. If it is moved again before accessing
it (a rare event I think) the client will just get a new URI again.
Do you see any problems ?
BTW, I also don't want depth locks and lock null resources compicating
my client.

Regards, 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 Monday, 18 October 1999 02:36:24 UTC