Hey, Thanks for reposting. It still shows up in the same thread for me, but I'll go with it. :)
> I have a "strawman" proposal, focused on stripping zope.component down > as far as possible: > > 1. Merge my branch which drops the deferred import stuff. > > .. note: > I'm about to do this merge, based on positive feedback on the list. Great! > 2. Move the persistent registry stuff out into another package, > including whatever support is needed to allow for people to migrate > existing persistent references. Effectively, this moves one "extra" > out to a package, *including* its testing dependencies. +1 > 3. Move the ZCML directive implementations out into another package, > taking the zope.security and zope.configuration dependencies along > with them. +1 > 4. Rework zope.hookable to use a pure-Python implementation via > descriptors, instead of the C extension. Make it a non-optional > dependency (but small and lightweight) of zope.component. If > *current* profiling shows that the hooked things are bottlenecks, > make the C version and optional replacement for the Python version. How do we do "current profiling"? Anyway, I'm +1 a pure-python implementation for zope.hookable, but we need to get some grasp of the performance implications nonetheless. Does anyone have any ideas on how determine the impact? > .. note: > In the meanwhile, I have done the latter, with a pure-Python > 'hookable' module in zope.component as a fallback for zope.hookable. +1 on this. > At the end, we would have three packages: > > zope.component > depends on: > - zope.interface > - zope.event > - zope.hookable (optional) > > zope.componentzcml (BIKESHED NAMING ALERT) > depends on: > - zope.configuration > - zope.security > - zope.configuration > - zope.proxy > - zope.i18nmessageid > > zope.persistentregistry (BIKESHED NAMING ALERT) > depends on: > - zope.configuration > - ZODB3 I'm fine with this naming. :) > Folks could then work on refactoring the new packages (e.g., depending > on a separate 'persistent' package, making the secuirity bits optional, > etc.). > Yes, this would be a great start, thanks very much for taking this initiative! To get back to repoze.zcml: it is my understanding that repoze.zcml contains some fixes to the way component registration is done in the context of multiple WSGI applications. I'm no expert on this myself, so I may understand this wrong, but that is my understanding. If that is correct, we could look at applying these lessons to zope.componentzcml. The trouble starts because we'd also need to apply those lessons to grokcore.component as well, which doesn't need to depend on zope.componentzcml at all. So it would seem applying this knowledge would touch quite a few places, and my instinct is to look for a way to share the implementation and knowledge in a single place. We might be able do this by placing some basic action implementations (or at least code that helps implementing such actions) in zope.component itself. This would NOT implement any ZCML directives nor introduce any dependencies (not even zope.configuration), but would be an API implementers of configuration mechanisms could then use. Perhaps this is overkill or not possible; I don't quite understand the issues involved, but I hope someone who does chips in. 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 )