> Betreff: Re: [Zope-dev] Zope.pipeline proposal
> Roger Ineichen wrote:
> > Hi Tres
> >>>> http://plope.com/whatsitdoing2
> >>>> This is why zope.pipeline is such an important effort to me.
> >>>> Not that it will immediately make things better, but it would
> >>>> hopefully open up a path to move the Zope Framework
> >> forward in this
> >>>> area.
> >>> I absolutly agree!
> >>> As far as I can see, the repoze sample doesn't open a ZODB
> >> which makes
> >>> it not really comparable.
> >> I think you've made Chris' point for him: nothing about the
> >> application being tested *requires* that there be a ZODB
> >> open; Grok's design forces opening one unconditionally,
> which is a
> >> layer of complexity which *can't be turned off.* The "conceptual"
> >> overhead of each of the frameworks is at least as important as the
> >> performance overhead.
> > Yes, that's true. But I like to see the real performance
> win within a
> > *real* application. My applications normaly do not only
> show a hello
> > world page ;-)
> > I also like to see how much the repoze method calls will
> grow if the
> > authentication, transaction, ZODB etc is involved.
> > I'm pretty sure that it will much less then 20 times like
> in the given
> > test. I'll also be happy if we will gain a 2 time
> perfomance factor in
> > a real comparable test app.
> > I've developed a prototyping package in my own personal repos which
> > tries to setup a site within some objects which I use with the old
> > zope server and a paste WSGI server setup.
> > This let us run performance tests against the ZODB.
> Probably I should
> > add that to the zope repos and we could start adding all
> our different
> > publishing implementations. This whould let us compare the
> same things
> > in a real world use case.
> While I think that would be a good thing, I do want to
> mention that it's not really the point of the "whatsitdoing"
> 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.
> In the meantime, we are proud of the work we've been doing to
> simplify Zopelike publishing, and the "whatsitdoing"
> benchmark was really just a mechanism to toot that particular
> horn. I'm not sure how to toot that horn without comparing
> it to Zope, so while I see that it has ruffled some feathers,
> I'll stand by the benchmark as a useful comparison. I'm
> pretty sure the stuff would fare pretty well on some other
> less objective benchmark (like "developer productvity" as you
> seem to be advocating).
> FTR, the "publishing implementation" you speak of above in
> the case of repoze is is really a different framework
> altogether: http://static.repoze.org/bfgdocs/ .
I see what you mean.
I really have to deep into the repoze packages. It defently
looks very promising!
Don't get me wrong. I really appreciate your great work.
It's one of this pieces we need for make better progress.
> - C
Zope-Dev maillist - Zope-Dev@zope.org
** No cross posts or HTML encoding! **
(Related lists -