Re: Locks and loopback bindings

Sorry I've been a spectator on this one as well.  I am uncomfortable 
about allowing loopback bindings at all, but I'm not sure what would 
improve the situation -- forbidding loopback bindings, fixing the lock 
interactions, or just letting server implementors sort things out.

lisa

On Dec 8, 2004, at 4:00 PM, Jim Whitehead wrote:

>
> Geoff Clemm writes:
> 	
>> But with the semantics that Jim suggests, some of those members will
> remain
>> mysteriously unlocked, and the editor just fails with "unexpectedly
> missing
>> lock" when the user attempts to edit (or even worse, allows the user 
>> to
> edit
>> an unlocked resource, without overwrite protection).
>
> and
> 	
>> Surely any server
>> that is bold enough to support both binding loops and depth locking 
>> would
>> support the DAV:lockroot property introduced a while ago to solve 
>> exactly
>> this problem of not knowing where a lock comes from.
>
> These are good points.
>
> That, plus the fact that I'm getting nowhere in convincing anyone else 
> to
> change the semantics of loopback bindings, leads me to concede this 
> point.
>
> It's now fine with me not to include any additional language in the 
> BIND
> specification about locks and lookback bindings.
>
> - Jim
>
>