[Zope-dev] Zope.pipeline proposal

[Martijn Faassen]

Chris McDonough wrote:
[snip]
> 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 components
> 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 needing
> to carry around 6-10 years of backwards compatibility baggage; it owes any 20-20
> 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 
minimum.

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.

Regards,

Martijn