On 3/4/09 1:07 AM, Chris McDonough wrote:
> Martin Aspeli wrote:
>> Chris McDonough wrote:
>>> Sorry, the "you" above in "you scolded" was Martin Aspeli, not Faassen.
>> Note that the "scolding" had something to do with you breaking Plone
>> trunk due to a transitive change in Chameleon, and the realisation that
>> from this point on, any package shared between repoze.bfg and Plone (or
>> anything else) that is configured with ZCML, will probably need to be
>> forked. We found a workaround with Chameleon, but not one that will scale.
> The fix is totally scalable and completely correct.  Chameleon.zpt just does 
> not
> have any (real) ZCML anymore.  Any package that has ZCML is, by definition,
> written for some framework as stuff that is meant to be overridden, otherwise 
> it
> wouldn't be written as configuration.  ZCML is unlike code in this way.  If it
> wasn't meant to be overridden, it would be in code.
> All packages which are meant to be maximally useful outside the scope of that
> framework should be split into two things: the library portion, then some
> portion that contains ZCML for gluing in to some framework that wants ZCML in
> some specific configuration.

When I read Martin's post, I had a similar reaction.  Namely, that the 
convenience of the Uberthing (Plone in this case) will always trump the 
desire of packages trying to survive on their own for new audiences.  At 
the time of the configuration scolding, I remember thinking: there's 
little interest here in Chameleon's goal to be bigger than Zope.  "Keep 
things convenient for us in Plone!"

Package sharing between repoze.bfg and Plone should not mean that BFG 
gets dragged down, paying for things it specifically doesn't want to 
eat.  BFG never claimed to sign up for Plone's contracts.

I sense the logic of Chris's position: if the Zope Framework is as big 
as every current use case in Zope2+Zope3+Grok+etc., with nine years of 
accumulations on each (3 forms systems in one of them), then we're 
missing the goal (IMO).  We'll make life incrementally better for 
ourselves, but we'll still scare off the folks who aren't after Uberthing.

Plone is going towards a smaller-and-smaller "core" that is only as big 
as the manpower to do a great job at keeping it stable.  Meaning, very 
small.  Hopefully the Zope Framework is a tiny little thing that pays 
only for what it eats.

Hopefully the goal is to make a very good microframework (or even 
better, set of libraries).  If "you can't make the best configuration 
language possible because one line of includes to get trusted adapters 
is an unconscionable burden" is the rule, then I know how this movie ends.


Zope-Dev maillist  -  Zope-Dev@zope.org
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://mail.zope.org/mailman/listinfo/zope )

Reply via email to