On 20 January 2011 15:08, Jason Garber <[email protected]> wrote: > While maintaining support for the WSGI standard, are you okay with extending > mod_wsgi with very apache-specific features? > I don't have anything exactly defined in mind, but most things I would ask > for would have to do with using apache to it's fullest possible extent.
In my restructuring of code, I am going to expose the high level functions for acquiring my named Python sub interpreters as what in Apache is called optional functions. These are registered in a table and can be looked up with another Apache module without that Apache module needing to be linked with the first. The idea therefore is that mod_wsgi would act as the master for Python initialisation and sub interpreter management. You could then write other special purpose C based Apache modules which themselves hook into Apache request processing phases where they need to and use those exposed mod_wsgi functions to get a handle to the desired sub interpreter and do call into Python code to do actual work. Technically this could mean that the access control, authentication and authorisation parts of mod_wsgi could themselves be dropped out of the core of mod_wsgi and offered instead as separate mod_authnz_python module. Piggy backing on this, have also thought about the idea of being able to write what is required for a special purpose Apache module as a simple Python code file. Ie., the code file says what phases you want to hook and where in that phase, plus provide the code for the hook. You would then run that Python code file through a script and it would generate C code for actual Apache module which would then be compiled into Apache .so module, with the original Python code file with your stuff in it, frozen and embedded with the .so itself so still only have single file to install. To do the latter would most likely still need to also make use of my SWIG bindings for Apache internals that I was working on. In summary, I actually want to try and break out the Apache specific bits into separate modules rather than be part of the core, albeit that core mod_wsgi.so would still need to be loaded for them to work, even if not hosting a WSGI application. The goal is to do it in such a way as to make it easy for people do create these separate modules without themselves needing to know how to write Apache C modules, which is where the code generator comes into it. Graham > -JG > On Wed, Jan 19, 2011 at 9:47 PM, Graham Dumpleton > <[email protected]> wrote: >> >> This email is an official call for feedback from you as a mod_wsgi >> user as to what new features you would like to see added to mod_wsgi. >> >> Part of the reason for the current code cleanup I am doing is to make >> it easier to add new features. I have for a long time had my own ideas >> for new features but my time to work on mod_wsgi has been quite >> limited for the last couple of years. This year though should be a lot >> different and expect to be able to do a fair bit of work on mod_wsgi >> to enhance and make it more versatile. >> >> Although I have my own ideas, I rarely hear from people out there >> actually using it as to what features they would like to see and which >> would make what they do easier. It seems you all just accept what you >> are given and don't question it. I am particularly surprised (at least >> that I know of), to not really see probing questions from people >> setting up these new breed of WSGI hosting services in the style of >> Heroku as to the best way they might use mod_wsgi, or to see feedback >> from them on what features they would like to see to make it easier. I >> know some are actually using gunicorn, but others are still using >> Apache/mod_wsgi. >> >> So, what new features would you like to see in mod_wsgi? >> >> I'll will describe one major feature just so people don't just ask for >> it when already well on the way to working out how to implement it. >> >> That one feature is the ability to define a template for a daemon >> process group with new daemon process groups setup according to that >> template being able to be started dynamically without having to >> restart Apache. That is, instead of having to change the static >> configuration of Apache, could be as simple as just dropping a WSGI >> script file in place and when a request occurs which gets routed to >> that, a new daemon process group for that application is created >> automatically, with it running with user/group corresponding to the >> ownership of the WSGI script file. >> >> Anyway, post your ideas and I'll comment as appropriate, indicating >> whether already being considered, not practical, or already >> implemented and you didn't know about it. >> >> Graham >> >> -- >> You received this message because you are subscribed to the Google Groups >> "modwsgi" group. >> To post to this group, send email to [email protected]. >> To unsubscribe from this group, send email to >> [email protected]. >> For more options, visit this group at >> http://groups.google.com/group/modwsgi?hl=en. >> > > -- > You received this message because you are subscribed to the Google Groups > "modwsgi" group. > To post to this group, send email to [email protected]. > To unsubscribe from this group, send email to > [email protected]. > For more options, visit this group at > http://groups.google.com/group/modwsgi?hl=en. > -- You received this message because you are subscribed to the Google Groups "modwsgi" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/modwsgi?hl=en.
