On 23/11/2007, Manlio Perillo <[EMAIL PROTECTED]> wrote: > Phillip J. Eby ha scritto: > > At 11:57 AM 11/23/2007 +0100, Manlio Perillo wrote: > >> Hi. > >> > >> As I have written in a previous thread, I would like to use nginx > >> logging system in a WSGI application (of course the same is valid for > >> Apache) > >> > >> A first problem is that the wsgi.errors stream defined in the > >> environment dictionary is valid only for the current request, but I want > >> to use a stream valid for the entire process lifetime. > >> > >> I think that there are two solutions: > >> 1) call an application supplied `init_application(environ)` callable, > >> where the environ dictionary contains the "right" wsgi.errors stream > >> object > >> 2) add to the environ dictionary a `wsgi.global_errors` stream object > >> > >> > >> Any suggestions? > > > > Yes: provide an 'nginx.global_errors' stream object, as a > > server-specific extension. > > > > Ok, thanks. > > I think that I will use the `mod_wsgi` "namespace", since this same > interface can be used by other WSGI gateway implementations embeded in a > web server.
Please don't use 'mod_wsgi', use 'nginx' as you originally said. There is already going to be enough confusion around you using the 'mod_wsgi' name when the Apache WSGI implementation came first. I really wish now that I had insisted you specifically call it 'nginx_wsgi' even though you based it on Apache mod_wsgi. To try to be compatible is one thing, to use the same name in a way that is confusing is just going to cause more and more problems down the track if nginx mod_wsgi does get to a point of being usuable. Whatever you do, please do not go releasing any distinct Python module/package called 'mod_wsgi' as the Apache mod_wsgi code is all set up around it being able to do that already, with the assumption that it has ownership of that namespace because it started using the name first. I am sure that others will possibly say that I shouldn't even be using it, but I am just following the tradition set by Apache in how it names its modules and it seems reasonable that I should be able to use that same name in Python module/package space much like mod_python already does. I would hope that Apache mod_wsgi is getting enough exposure now that it would be accepted that it has reasonable priority on the name. If people want to argue the point, then by all means suggest something else. At the moment, for Apache mod_wsgi 1.X it uses of the name is internal only and its use mainly symbolic, but in Apache mod_wsgi 2.0 release candidates it does extend outside of the process in as much as it will attempt to import a Python module/package of that name as a means of extending Apache mod_wsgi with additional optional extensions, albeit no such package of extensions has yet been publicly released. So, it isn't necessarily too late to change it. Note that 'apache' can't be used in place of 'mod_wsgi' for Python module/package name, as there is already Python code available using that for SWIG bindings for internal Apache APIs. Any suggestions on a consensus on how we resolve all this and avoid arguments down the track are more than welcome. Presuming that is that people want to object to Apache mod_wsgi assuming that it can use 'mod_wsgi' for the name of a Python module/package. :-) Graham _______________________________________________ Web-SIG mailing list Web-SIG@python.org Web SIG: http://www.python.org/sigs/web-sig Unsubscribe: http://mail.python.org/mailman/options/web-sig/archive%40mail-archive.com
