Re: Locking: Implementation Considerations

GEoff, before you go on vacation, it would probably be valuable if you were your
own devil's advocate here....

<GC>
So what conclusion can one draw from all this?

One possibility is to say that locking is largely unneccessary in the
presence of versioning (after all, everything is read-only unless you
explicitly check it out into your workspace), so versioning servers
just won't bother with locking at all.  This would have an unfortunate
interoperability result on Class-2 clients try to work with versioning
servers.
</GC>
So why *NOT* let versioning replace locking?  Is there a form of locking that
provides value add over versioning?  How mature is the versioning work?   Be
your own devil's advocate...


<GC>
Another possibility is to downgrade Depth:infinity locking to a MAY,
thereby warning clients that they are likely to find this not supported,
and to turn the default lock into Depth:0, instead of Depth:infinity.
The latter will cause an interoperability issue with existing class-2
servers, but since there aren't many of those yet, if we move fast, this
would probably be OK.
</GC>
There must be issues with your first proposal or you wouldn't have offered this
one.  Let's hear them.  :-)

I just want to get your thoughts here before you go.  I'm sure we'll all be
discussing this while you're gone.

Cheers,

Jason.