On 24/11/2007, Manlio Perillo <[EMAIL PROTECTED]> wrote: > Graham Dumpleton ha scritto: > > 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. > > But this is a "no problem" :). > A WSGI application can be embedded in Apache *or* in nginx. > > I would like to use a common name/interface so applications can easily > be ported from Nginx to Apache and viceversa.
I am not sure you understood what I meant. I already put out software called 'mod_wsgi'. This contains an Apache module only. I also already put out software called 'ap_swig_py'. The contents of this when compiled and installed, will create in Python site-packages directory a Python package called 'apache'. This contains SWIG bindings for internal Apache APIs. It is usable from WSGI applications running under Apache mod_wsgi. Technically the SWIG bindings are also usable from mod_python, giving it much better access to internal Apache APIs that it itself provides. I also am preparing some software called 'mod_wsgi_py'. The contents of this package when installed, will create in Python site-packages directory a corresponding Python package called 'mod_wsgi', matching the name of the Apache module. This package will contain a mix of generic WSGI components as well as some which will only work when used in the context of Apache mod_wsgi. In some cases the WSGI components will use a generic mechanism when not run under Apache mod_wsgi, but when Apache mod_wsgi is used a better more efficient mechanism will be used which hooks in to the internals of Apache to do stuff. When something hooks into Apache, it may be through using 'ap_swig_py' bindings, or through direct C extensions custom built for the purpose. However it is done, the intent is that it will be all transparent to the code using it. Examples of components that would be in the Python package installed by 'mod_wsgi_py' would be things like a WSGI component for performing a sub request back into the same Apache web server and then being able to filter the response just like it was returned from any other WSGI component. A component such as the ApacheLogHandler could also be placed in this package, with Apache mod_wsgi, when the corresponding Python mod_wsgi package was installed, triggering some initialisation code which would install that as the root handler for the 'logging' module, thus allowing the 'logging' module to log to Apache error logs with levels specified by user code. So, in other words, the 'mod_wsig_py' software would not be required to use Apache mod_wsgi, but if you have it present, you will have additional features. At the same time, you could use 'mod_wsgi_py' even if you aren't running under Apache mod_wsgi, but could use it in other WSGI hosting solutions, even under wsgiref server if you wanted to. It would either replace components with something equivalent that works outside of Apache, or the component wouldn't be available if no other choice. This would be useful for testing or development outside of Apache. My concerns are that if you were to separately produce a package which installs into site-packages a Python module or package called 'mod_wsgi' there will be a direct clash. The other concern is that if you have followed the Apache mod_wsgi approach of internally creating a 'mod_wsgi' Python module in sys.modules as a place holder and storing of version information etc, then anyone using the installed Python 'mod_wsgi' package from 'mod_wsgi_py' wouldn't be able to run their application with the nginx WSGI adapter. As your placeholder will prevent it from being imported. In latest Apache mod_wsgi I do various checks and only create the placeholder module if the real package in site-packages is present. Thus, to avoid problems you really want to be avoiding using the 'mod_wsgi' name in any Python context, whether that be in the names of Python modules or as a prefix in the WSGI environment passed to applications. Using the same name in your version as what Apache mod_wsgi uses isn't going to gain you anything and because there will inevitably be subtle differences or incompatibilities between the two, using the same naming schemes will just make it harder where user code does have to be able to distinguish between the two. 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
