[Zope-dev] Zope 2 WSGI investigation

[Chris McDonough]

On Tue, 2012-01-03 at 07:32 +0000, Martin Aspeli wrote:
> On 3 January 2012 06:39, Chris McDonough <chrism at plope.com> wrote:
> > On Mon, 2012-01-02 at 10:39 +0000, Martin Aspeli wrote:
> >> On 2 January 2012 08:50, Wichert Akkerman <wichert at wiggy.net> wrote:
> >> > On 01/01/2012 08:39 PM, Martin Aspeli wrote:
> >> >>
> >> >> Hi,
> >> >>
> >> >> There are three known WSGI implementations of the Zope 2 publisher.
> >> >> I've had a look at them and made some notes about what I think
> >> >> provides the best story:
> >> >>
> >> >> ## Zope 2.13 WSGIPublisher
> >> >>
> >> >> Pros:
> >> >>
> >> >> * Allows distributed transaction management with repoze.tm2
> >> >> * Allows distributed retry with repoze.retry
> >> >> * Ships with Zope
> >> >> * Quite simple
> >> >>
> >> >> Cons:
> >> >>
> >> >> * Requires repoze.tm2 and repoze.rety
> >> >
> >> >
> >> > Why is that a con? I use repoze.tm2 and repoze.retry with all my pyramid
> >> > projects and they work beautifully.
> >>
> >> Only insofar as it means you have to have these in your WSGI pipeline
> >> or it won't work, so there are more places things can go wrong.
> >>
> >> You'll note that I also consider not supporting such things a con for
> >> infrae.wsgi. I wouldn't get too hung up on it, I was mainly just
> >> trying to bring out the differences. It'd be nice if it wasn't a hard
> >> requirement, though.
> >
> > FWIW, when I wrote repoze.tm2 I did not know that the transaction module
> > already supported retry, so at least repoze.rety should die in favor of
> > logic in something-like-repoze.tm2 that looks a little more like this:
> >
> > https://github.com/Pylons/pyramid_tm/blob/master/pyramid_tm/__init__.py#L49
> >
> > (that's obviously not WSGI middleware, I'm just showing what the general
> > logic should look like)
> 
> Am I right in thinking Pyramid no longer uses repoze.tm2 or a
> middleware approach? What was the rationale for that design decision?

You're right, Pyramid scaffolding no longer supplies repoze.tm2 or any
other WSGI middleware component for handling transaction commits/aborts.
Instead, it uses a Pyramid "tween", which is sort of like internal
Pyramid middleware inasmuch as its a user-manageable functional
composition terminating at the application.  See
http://www.slideshare.net/aconrad/alex-conrad-pyramid-tweens-ploneconf-2011

Tweens can be reordeded arbitrarily, and the Pyramid exception handling
logic (which locates and executes a Pyramid view when an application
exception is raised) is itself a tween.

The rationale is that application-specific error logic often needs to be
executed after the transaction has been committed or aborted due to an
exception.  For example, if an exception is raised by an application,
you'd like the system to abort the transaction, then potentially display
a custom internal server error page (e.g. twitter fail-whale).  People
want to be able to write the error logic within their existing Pyramid
development environment (where they have access to templating systems, a
real request object, and possibly their database and other niceties)
instead of as WSGI middleware higher in the stack than the transaction
manager.

The pyramid debug toolbar (the thing that shows the pretty debug pages
described at
http://docs.pylonsproject.org/projects/pyramid_debugtoolbar/en/latest/)
is also a tween, which means it has access to the Pyramid environment
that WSGI middleware could not (such as access to the registry, allowing
us to display view-configuration information, information about routes,
etc).  For us, this replaced our use of WebError, much as our use of
pyramid_tm replaced our use of repoze.tm2, for mostly the same reasons.

FWIW, I believe Tres still disagrees strongly with this decision.

- C