Breaking this out as the thread has got overlong. On 4 July 2011 09:49, Sylvain Viollon <sylvain@infrae.com> wrote:
On Sun, 03 Jul 2011 01:09:17 -0400 Chris McDonough <chrism@plope.com> wrote:
On Sun, 2011-07-03 at 03:41 +0200, Hanno Schlichting wrote:
Hello,
- Continue to remove functionality tailored for TTW development, like SiteRoot, AccessRules, HelpSys and step-by-step most of the ZMI - Document and use the WSGI publisher and remove obsoleted functionality like the virtual host monster, error_log, ZServer/medusa, zopectl/zdaemon
Zope still needs to the virtual host monster (or something like it) even with the WSGI publisher; there's nothing equivalent in the WSGI world (unless you could repoze.vhm, which is essentially just the virtual host monster, and probably doesn't need to live in middleware; no one uses it except people who use repoze.zope2).
I have my own WSGI implementation, since a while, that works perfectly (infrae.wsgi), and I still do use the VirtualHostMonster (you can trash all the other things).
I agree that its code might not been the best in the world, but it works for the moment and does what it says (I would love to see shiftNameToApplication implemented with more than one pass).
I will sad to learn that this goes away, if nothing replace it. I kind of don't like the WSGI approach of cutting the database, traversing, authorization, rewriting Zope 2 concepts into middleware as I think they don't really fit the design of pipes provided by the WSGI middleware concept (but I do use middlewares for other things with Zope 2).
I was interested to see that Pyramid seems to be experimenting with a non-wsgi approach now too for transaction integration (http://groups.google.com/group/pylons-devel/browse_thread/thread/f05c56072e4....) I really don't have enough experience with WSGI to know which is the best way to do it. I took a brief look at the documentation at http://www.infrae.com/download/tools/infrae.wsgi where some of the motivations behind it are mentioned. The builtin Zope2 WSGI publisher is still very new, and seems to have some rough edges still when running in mod_wsgi (possibly due to conflicts with Zope registered signal handlers.) Is it only that you think that the Zope2 WSGI publisher is not ready yet, or are there other problems? I'd certainly support simplifying the publisher, it has grown very complex as more and more functionality has been grafted on over the years. In the long run I'd much rather see something that only used __getitem__ for traversal and never getattr. Laurence
On Thu, 7 Jul 2011 16:15:38 +0100 Laurence Rowe <l@lrowe.co.uk> wrote: Hello,
I was interested to see that Pyramid seems to be experimenting with a non-wsgi approach now too for transaction integration (http://groups.google.com/group/pylons-devel/browse_thread/thread/f05c56072e4....) I really don't have enough experience with WSGI to know which is the best way to do it.
I took a brief look at the documentation at http://www.infrae.com/download/tools/infrae.wsgi where some of the motivations behind it are mentioned. The builtin Zope2 WSGI publisher is still very new, and seems to have some rough edges still when running in mod_wsgi (possibly due to conflicts with Zope registered signal handlers.) Is it only that you think that the Zope2 WSGI publisher is not ready yet, or are there other problems?
The main reason I made this project (infrae.wsgi) is that I had a customer that wanted to have Zope running in a WSGI stack with some repoze.bfg application, one year ago. It was for Zope 2.12 (or even 2.11, I don't remember well). I tested the WSGIPublisher in that Zope version, and I got errors as soon as I tried something more complicated than a simple hello world. (Opening the ZMI didn't work). I didn't even test with mod_wsgi at that time. Repoze.zope2 was for much older versions of Zope 2 and didn't work either. So it was not definitely ready yet. I saw since that lot of efforts have been made, and the default WSGI publisher works probably better now in 2.13, or the trunk. What infrae.wsgi does, is providing: - a (simple) alternate boot code for Zope : not all the parameters of the zope.conf are applied ; mainly only DB configuration, products and ZCML loading are done. No signal handling, no logging configuration (just using Python logging facilities and Paster configuration for it works), nor any other parameters that would be related to the server part are done for example, - an equivalent of the WSGIPublisher code (written in completely different fashion that the default WSGIPublisher code, since I could not get my head around that code to fix the errors I encountered), - support to get zope.testbrowser working with this (that I don't use anymore actually). Testing code that do streaming with Products.File.testbrowser doesn't work (the magic is in ZServer, and the TestBrowser is hooked before), this fix this issue. After I changed it to have a better and more useful error reporting by default (which is nice when customer sends you only the error, and don't tell you what they did), and a different way to render errors (I find the code completely crazy in Zope 2 for that). Because of that last point, it is not really compatible Zope 2 100%. I use it on production for one year now, on big sites, and didn't had any problem.
I'd certainly support simplifying the publisher, it has grown very complex as more and more functionality has been grafted on over the years. In the long run I'd much rather see something that only used __getitem__ for traversal and never getattr.
I would love to have something more easy to understand and use, with less magic, and not included in the REQUEST like that. Regards, Sylvain, -- Sylvain Viollon -- Infrae t +31 10 243 7051 -- http://infrae.com Hoevestraat 10 3033GC Rotterdam -- The Netherlands
participants (2)
-
Laurence Rowe -
Sylvain Viollon