On 3 January 2012 06:39, Chris McDonough <chrism@plope.com> wrote:
On Mon, 2012-01-02 at 10:39 +0000, Martin Aspeli wrote:
On 2 January 2012 08:50, Wichert Akkerman <wichert@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? Martin