[Zope-dev] Zope.pipeline proposal

[Chris McDonough]

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/ .

- C