Chris McDonough wrote:
> Martijn Faassen wrote:
>> Martin Aspeli wrote:
>>> You and I had a discussion a while back about forking the zope.component
>>> ZCML directives, and how it would've been better to work within the
>>> boundaries of the Zope packages so that everyone who wanted to lose the
>>> zope.security dependency could benefit, rather than fork this and all
>>> other configuration that depends on the core ZCML directives.
> As I remember it, you scolded me about doing it, then when I did it anyway, it
> worked its way over to the Grok list, where any alternate idea other than a
> plain fork died on the vine. That's what I figured was going to happen, so
> glad I actually took action.
Huh? We need a refactored zope.component for the Grok project as well.
Why did it die on the vine? Perhaps if someone had been integrating
these experiences and requirements properly on zope-dev it'd have
transformed into positive improvements in zope.component itself by now.
> Frankly, I don't care that I had to create alternative ZCML directives. This
> was, and is, and always will have been, the right thing to do. In fact, the
> only thing preventing Grok or anyone else from using the stuff created out of
> that effort wholesale (repoze.zcml) is the *brand*.
That's incorrect. We already have an implementation of alternate
directive (aka grokkers) to register the zope.component components in
grokcore.component, and have had them for much longer than you did.
Adding a *third* way to configure components, i.e. repoze.zcml, to the
mix is hardly going to improve matters for Grok. It's useless anyway as
we need to support the zope.component[ZCML] way anyway for ZCML, and
support grokcore.component for code that does it the Grok way.
I'd rather have one underlying action API that did the minimal but right
thing in zope.component that grokcore.component and repoze.zcml and the
Zope Framework (with its additional requirements for security) can all
Switching over to repoze.zcml would only gain Grok *more* code and a
harder to comprehend situation.
And you think it's all due to the brand...
> I don't care about
> Zope-the-brand anymore, I just care about Zope-the-technologies. Why would
> fact that this more reasonable set of directives is not named Zope anymore
> matter? What about that whole situation was not a win?
I already spelled out the above on the grok-dev mailing list before, but
you didn't seem to pick up on my explanation.
>> When I brought up the issue of trying to improve zope.component
>> recently, I got a lot of divergent feedback and nothing happened. It'd
>> be nice if instead such energy instead resulted in a concrete set of
> I didn't participate because I had already scratched that particular itch. I
> created something that *everyone* can use; it might not be named Zope, so be
I pointed out above why it'd be not very useful for Grok to use it. In
fact you created something that is redundant if you use the rest of the
Zope Framework as well (or even just zope.component[zcml]). It isn't
something that *everybody* can use just like that.
Forking is one way to solve the problem and forget about it, if you
don't care about compatibility with the Zope Framework. That's fine.
It's something you have the freedom to do of course and undoubtedly you
are much happier with it. It's also unfortunate for me, as your
improvements are not making in into the shared component.
So while the problem is solved for you, it isn't solved for me. Grok has
different goals concerning compatibility with the Zope Framework, and
therefore more interest in improving the underlying framework itself.
These are different philosophies. You with your philosophy should have
no problem with me trying to improve the framework experience though, as
you can go off on your own anyway and cooperate on bits of it whenever
you want. So I find it frustrating to hear you say "no" so much now.
It's fine if you don't care about the "Zope" brand anymore, but I'm
still allowed to care about it, right?
Zope-Dev maillist - Zope-Dev@zope.org
** No cross posts or HTML encoding! **
(Related lists -