Hash: SHA1

Chris McDonough wrote:
> Hanno Schlichting wrote:
>> Chris McDonough wrote:
>>> Maybe there's some potential to create a set of core ZCML registration 
>>> handlers
>>> for utility, adapter, subscriber, and interace that are not actually part of
>>> BFG, but on which BFG and other non-Zope apps could depend.  I suspect this 
>>> is
>>> the only realistic way to go forward: I don't think it's reasonable to tell 
>>> the
>>> people who have Zope apps in production which use these declarations that 
>>> they
>>> won't be able to use untrusted code or permission declarations, or the 
>>> global
>>> registry.
>> Should this discussion happen on the zope-dev list or is that too
>> hostile these days ;)
> I'd be happy if this discussion migrated to zope-dev.
>> >From my point of view, configuration of components is an area where
>> every Zope-based project takes a different approach to right now:
>> - Zope3 has its own handlers tied in deeply into the rest of the application
>> - Zope2 has its own handlers (in Products.Five) which are highly
>> dependent on the rest of the application
>> - Grok uses a different approach and has written its own configuration
>> approach
>> - Plone might want to adopt a Grok-style approach and will need to use
>> yet another kind of five.grok or similar handlers
>> - repoze.bfg now gained its own implementation of the core ZCML handlers
>> What all projects have in common, is the abstract concept behind those
>> handlers and the dependency on zope.component and zope.interface. We all
>> have interfaces, utilities and adapters.
>> What is different is the exact way these concepts need to be configured
>> to fit into the framework. One problematic bit is that depending on the
>> framework the configured result actually has different semantics at some
>> points as well.
>> What can we do about this?
>> Every framework makes it more obvious that they have different
>> implementations of the same concepts and provide them in a different
>> namespace / approach? That results in integration packages to be
>> required to be able to use a package from one framework in a different one.

No:  just *don't use the directives*.  Reusing policy-laden
configuration is an anti-goal, compared to re-using software.

>> We all claim to be in the same namespace and let the result of the
>> configuration be dependent on the framework it is used in? That is more
>> convenient to (re-) use but has the risk of hiding the semantic differences.

- -100 to that option.  This is why we have namespaces in the first place.

> It just doesn't seem feasible to break backwards compatibility to make the
> "core" directives do less all the time.
> It'd work to add knobs to the core directive packages that let it detect 
> whether
> the directives use more advanced features like "trusted" and "permission",  
> but
> it might make the ZCA code a little convoluted.  I suspect that floating that
> idea on zope-dev would be the only way to tell.  I wonder if anyone has enough
> context using the ZCA outside of Zope for the idea itself to make much sense 
> to
> them.

This is why stripping dependencies is hard:  the dependencies don't hurt
the folks who want the policies served by them, while stripping them
out, and parameterizing the code which currently hardwires the policies,
makes those same developers' lives harder (now they have to add the
dependncies to their own code) and their code more convoluted.  We can't
even get them to agree to simple things like stripping out *test*
dependencies from the main 'install_requires';  what makes you think
they would be willing to move the "Zope{2,3}-only" stuff out?

Note that one change I would make to the docs is to make using the 'bfg'
namespace *not* the default in the examples;  marking each non-Zope
directive with 'bfg:' (in the examples, not necessarily in a real-world
config) would remind people, "this is not your father's Oldzopemobile,"
as is true already for 'bfg:view'.

- --
Tres Seaver          +1 540-429-0999          tsea...@palladion.com
Palladion Software   "Excellence by Design"    http://palladion.com
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

Repoze-dev mailing list

Reply via email to