Hi there, Paul Everitt wrote: [snip] > Hopefully the Zope Framework proposal helps untangle this, and gets to a > point where you don't have to keep the Uberthing in your head when doing > something small.
It's not small, as it has an impact on a lot of things that build on zope.component. Changing things low in something that lots of people have built stacks on is almost never a small change. Just look at Python 3, which makes a bunch of actually rather small but still incompatible changes to the language. While small from the perspective of the language, they're *huge* from the perspective of the users. So you need ways to coordinate such changes. I hope that having someone actually taking responsibility for zope.component's evolution can get the zope.security dependency out of it, and then improvements of repoze.zcml into it, or alternatively move the ZCML implementations *entirely* out of zope.component. I hope Chris will coordinate with us where necessary. I don't want security bits to sit around in zope.component either. grokcore.component doesn't need that code, just like repoze.zcml doesn't need that code. It's still there, even if you use repoze.zcml, just inactive. I tried to propose various ways forward. I got nowhere as I got 10 people giving 10 answers. Original problem unresolved. I'd like there to be someone who can make this decision and I'd like this someone to usually make *positive* decisions that work towards resolving the underlying issue, while coordinating with everybody that is impacted by this decision. The zope.component ZCML case was very much in my head as I wrote this proposal. Regards, Martijn _______________________________________________ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
