[Zope-dev] Stripping down zope.component

[Martijn Faassen]

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