Re: webdav locking (was Re: [Zope3-dev] Re: [Zope-dev] Two visions)
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. 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 and like yourself I am going to quite busy over the next few weeks so it will probably be slow in coming. But I would appreciate what you think about this particular use case. Some background: The current webdav spec RFC2518 will hopefully be deprecated in the next few months. The new specification which has just in the last fortnight gone into last call stage of development, contains a near rewrite of the locking sections to make things easier (so they say), especially relating to the lock null resources and locks on collections. And I am aiming at implementing these features as it is what apache does and I get the impresion that the writers of the spec have clearly learned from past problems implementing this feature. But one thing the new spec goes into that zope.locking doesn't have (I don't think) is when you lock a collection with infinite depth. The new specification says that the collection and all the descendents objects are to locked against one lock token. The collection been locked is called the lockroot and all descendent objects are then indirectly locked against this lock token. The specification goes on to say that if an object is added to such a locked folder then it is also automatically indirectly locked against the same lock token has the folder. Any successful unlock operation on a locked object must also unlock all resources associated with this lock token. (Sorry I the previous paragraph isn't completely clear but section 6.1 and 7.4 of http://www.ietf.org/internet-drafts/draft-ietf-webdav-rfc2518bis-14.txt explains this feature a lot better if I didn't make sense) Any ideas on this?, is it feasible or not within zope.locking? If Jim successfully gets zc.sharing open sourced today then we have some zope.locking/zc.sharing integration that (as one integration option for zope.locking tokens) can filter so that only people with locks have edit privileges. It seems to work pretty well, but it's also just one way to use the zope.locking tokens. As with zope.app.locking, the locks themselves are purely advisory until you put in some code to make them enforced somehow. Can't wait. zope.locking can do exclusive lock tokens, shared lock tokens, freeze tokens (effectively, no one gets the lock), and can also support custom tokens if you need them. Cheers, Michael -- Michael Kerrin 55 Fitzwilliam Sq., Dublin 2. Tel: 087 688 3894 ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: webdav locking (was Re: [Zope3-dev] Re: [Zope-dev] Two visions)
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 ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
webdav locking (was Re: [Zope3-dev] Re: [Zope-dev] Two visions)
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. If Jim successfully gets zc.sharing open sourced today then we have some zope.locking/zc.sharing integration that (as one integration option for zope.locking tokens) can filter so that only people with locks have edit privileges. It seems to work pretty well, but it's also just one way to use the zope.locking tokens. As with zope.app.locking, the locks themselves are purely advisory until you put in some code to make them enforced somehow. zope.locking can do exclusive lock tokens, shared lock tokens, freeze tokens (effectively, no one gets the lock), and can also support custom tokens if you need them. Gary ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
