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 _______________________________________________ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )