[Zope-dev] Zope.pipeline proposal

[Roger Ineichen]

Hi Chris

> 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 
> connection 
> >> 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" 
> benchmark.
> 
> 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!

btw,
Don't get me wrong. I really appreciate your great work.
It's one of this pieces we need for make better progress.

Regards
Roger Ineichen

> - C
>