webdav locking (was Re: [Zope3-dev] Re: [Zope-dev] Two visions)

[Gary Poster]

On Mar 2, 2006, at 4:58 PM, Michael Kerrin wrote:

> Hi Gary,
>
> On Wednesday 01 March 2006 15:33, Gary Poster wrote:
>> On Mar 1, 2006, at 10:13 AM, Michael Kerrin wrote:
>>> so it doesn't get to the locking tests (which will fail) but this
>>> is good
>>> thing to aim at :-)
>>
>> Hey Michael.  What are you planning to do with the locking stuff?
>> I'd like to see zope.locking (http://svn.zope.org/zope.locking/)
>> used, rather than zope.app.locking.  It learns from zope.app.locking
>> while also addressing some issues and adding some features.  I don't
>> have time to do much about proposing it and integrating it, though.
>> Maybe I can squeeze in a bit next week or week after.
> Brillant - Locking is next on my hit list, and I am planing on using
> zope.locking to improve the current implementation.

Cool.

> I have an issue with
> zope.locking on a collection with infinite depth but I am planing  
> on ignoring
> this use case for the moment and get the rest of the locking  
> working without
> any infinite depth support[...]

> Any ideas on this?, is it feasible or not within zope.locking?

It seems reasonable, I think.  I'd prefer to do it with some code on  
top of zope.locking--within the webdav package, for instance--but am  
not totally opposed to pushing it down into zope.locking.

The basic idea would be that webdav would use a special kind of lock  
token that marked an infinite depth lock (maybe even just directly  
providing an interface on the existing lock tokens) whenever you  
wanted to make an infinite depth lock.  Then webdav asking "are you  
locked?" for a given object would need to not only ask the object but  
also walk up the parents to ask each of them if they are locked with  
an infinite depth token.  Since the new spec contemplates "sub  
locks"--locks within the infinite lock--it seems to model pretty well.

The only concern I'd have is that making checks like that into a  
security policy might be more work than we would want...although the  
default security policy collects information from the __parent__s, so  
maybe it wouldn't be too bad.

If we did push this down into zope.locking, my current thinking is  
that I'd like to have the transitive lock search be some additional  
API, maybe in a separate interface, and not modify any of the current  
methods.

In terms of code alone, though, this seems very doable, maybe even  
simple. :-)

Gary