[Zope-dev] Zope 2 WSGI investigation

[Sylvain Viollon]

Op 1 jan 2012, om 20:39 heeft Martin Aspeli het volgende geschreven:

> 
> Hi,
> 

  Hello,

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

[...]

> 
> ## infrae.wsgi
> 
> Pros:
> 
> * Clean and well documented
> * Properly emits publication events
> * Supports streaming

  Those two points are features I use actively in Silva, and where motivation for me to work on my
implementation. (I had a look before to repoze.zope2 and the default Zope 2 support, back in 2.12).

> * Supports simplified virtual hosting with X-VHM-Host

  That is not completely true. I support setting the hostname, however to set a
virtual path, you need to do this during traversing, which is done in BaseRequest,
that I don't change (because it is a big large blob of code where you cannot really plug anything in it, or
change only a few line in it without changing everything). 

  In production we use mod_rewrite to rewrite the URL with an old
VirtualHostMonster url and pass it to mod_wsgi with the help of the flags PT.

  When I boot Zope in infrae.wsgi, I don't do anything that is the responsibility of the server,
like setup up user, logs, signals and so on, so that doesn't interfere with the WSGI server,
so this works well with all the WSGI servers, including mod_wsgi (that was on of the issues
with the default Zope 2 WSGI support).


> * Supports exception handling / error views
> * Reportedly has significant production use
> 

   We have customers now using for more than one year in production, for large sites
(30GB+ Data.fs) without problems.

> Cons:
> 
> * Not 100% compatible (but close and fixable) - fix to make
> plone.transformchain work is here: https://gist.github.com/1547328

   There are a couple of methods on the response that would probably a bit more of work
in order to be a bit more compatible with what Zope 2 does. I just implemented what was required
to get the ZMI and Silva work correctly.

> * Unnecessary five.grok dependency (but easy to rewrite to use ZCML
> registration)

   This is only used to register default error views (and the error log page).

> * No support for middleware transaction and retry management, so these
> can't be distributed across a WSGI pipeline
> * Error logging will not support ZMI error_log and assumes single process

  As matter of fact, I have more detailed log than the default Zope 2 error logging, that include lot of request
information. I use after the filesystem logs afterward to investigate issues instead of going into of the ZMI.
This is because we often don't have access to the ZMI of our customers, however they can send us the
logs in case of problems.

  We use Paster as well in the stack, and use it to configure the Python logging process, you can configure
there a logging to syslog, and after having a central syslog server. I think it is more professional like this,
than using a tool in Zope's UI.

> * Error handling is slightly different to standard publisher's
> exception views, and also does not honour existing
> standard_error_message etc
> 

   I did this mostly because for each error I wanted to know what was the last valid
context I had before I got an error. This information is lost in how Zope 2 does it, because mostly
the error handling goes through at least 5 different hooks. After that was to get something
much more simple.

[...]

> ## Suggested approach going forward
> 
> * Integrate infrae.wsgi into Zope 2

  If that happens, like I said, we would probably need a bit more of work to be compatible with the standard 
Zope 2 response (for instance setHeader is aliased to addHeader, but they should behave a bit differently).

  I can help on my free time to work on any official WSGI support in Zope 2, and simplification of the
publication process.

> * Remove its five.grok dependency

  That would be no problem.
 
> * Use the same exception-views protocol as ZPublisher (mainly, that
> the view name is ``index.html``)

  We could update it to be more compatible with Zope 2, and use the Zope 2 error log,
but that would need some cleanup work in this last one which is overcomplicated for what it does.

> * Stop using __ 'private' variables in response.py  to make it easier
> to work with
> * Add some BBB support for existing error logging and error messages
> 

  Sure.

  Regards,

  Sylvain,


-- 
Sylvain Viollon -- Infrae
t +31 10 243 7051 -- http://infrae.com
Hoevestraat 10 3033GC Rotterdam -- The Netherlands