Chris McDonough wrote:
> While I think that would be a good thing, I do want to mention that it's not
> really the point of the "whatsitdoing" benchmark.
Right, agreed. I think it's more important to make the Zope Framework
more comprehensible than it is to improve its performance. Its
performance is already fine for many purposes and it'll be much easier
to improve once the structure is more comprehensible anyway.
We have currently two efforts going on to increase comprehensibility of
the Zope Framework:
* cutting away code that isn't needed or is unnecessarily pulled in.
This is the dependency refactoring work.
* Shane's zope.pipeline work.
I'm pretty pleased we have all of this going, as long as we keep it up. :)
That we need to clean up the framework became clear to me much before
Chris started pointing out things in the "whatsitdoing" benchmark
though, but earlier discussions about Repoze (in particular with Tres at
DZUG last september) did help shape my ideas.
> Repoze stuff typically tries to simplify each component in the set of
> used to service a goal, sometimes at the expense of at least some backwards
> compatibility or excessive configurability. On the other hand, Zope3 and Grok
> tend to keep backwards compatibility and configurability sometimes at the
> expense of verbosity and extra runtime expense. They are just somewhat
> different goals. Repoze stuff therefore has the major advantage of not
> to carry around 6-10 years of backwards compatibility baggage; it owes any
> hindsight in these cases of course directly to Zope.
I do believe we can move the existing Zope Framework forward quite a bit
in the right direction too. Perhaps we'll have to give up some
backwards compatibility, but we can probably keep most of the code
working. We haven't been afraid to break things occasionally with Grok
but we've found that with good upgrade notes we can keep the pain to a
This work should also result in more reusable components for Repoze and
more use of Repoze components within code that uses the Zope Framework
(such as Grok), so that should make us all happy. :)
Luckily we're not starting with a very bad situation here. We have the
benefit that the Zope Framework (and Grok) are made out of pieces that
are at least *somewhat* tractable and replaceable.
Zope-Dev maillist - Zope-Dev@zope.org
** No cross posts or HTML encoding! **
(Related lists -