On 22 October 2010 17:24, Deron Meranda <[email protected]> wrote: > On Fri, Oct 22, 2010 at 1:14 AM, Graham Dumpleton > <[email protected]> wrote: >> As to further changes to mod_wsgi itself to support further hooking in >> Apache, that will almost certainly never happen. It has already got >> too messy as it is. > > Understood. > > I guess I see a couple different purposes for mixing Python with Apache. > The first/primary is to use Python to provide dynamic content, and for > this I'm certainly of the opinion that WSGI (mod_wsgi) is the best way > to proceed. > > But the other purpose is to allow Python to be used in many places > where Apache can be "customized", and this includes its use in many > of the hooks, etc. > > Obviously the deprecated mod_python tried to do both. But if its > too complicated (or a costly diversion) mod_wsgi probably should > just concentrate on the WSGI part. > > > I may actually play with making a separate module specifically to > try to cover Apache hooking, but not to compete with the main > content-providing as with mod_wsgi. I may do this mostly just to try > to strengthen my own personal knowledge and confidence of dealing > with Apache internals; maybe nothing will come of it, but who knows. > > So a few questions Graham: > > Have you then pretty much shelved any idea of resurrecting some > of the missing mod_python like functionality at this point?
As part of mod_wsgi, yes, don't really want to go that path. > A separate module would still need to interact with the Python > states, threads, and interpreters. Probably it would require > mod_wsgi so it could re-use the interpreter management. > Do you have any specific notes on how to best be compatible > with mod_wsgi, especially for initialization? (do it the mod_python > way, or is there something better to do)? > > If I wanted a way to pass information up through an early hook into > mod_wsgi, do you think the ap request notes table is a reasonable > mechanism? Overall, the way mod_python does things is to me pretty crappy. The same can be said for many Apache modules that try and provide a generic hooking mechanism for scripting languages. Ie., mod_lua, mod_perl (??). The problem is that although they allowing hooking, they don't allow you to hook anything but the middle phase of that hook. It doesn't allow you too hook as really first, first, last or really last. Further, even within the middle phase, it doesn't allow you to control when that handler is executed relative to other Apache modules. Although you could technically make these script modules more elaborate by allowing the other phases of a specific hook to be hooked, all this will do is slow down Apache because even if not used, the module still has to intercept it and do a lookup to see if anything is registered. So, when it comes to writing decent module functionality, these script modules like mod_python do a pretty crappy job. What I would like to have worked on, but due to no time have pretty well given up on, is the ability to write the basis of an Apache module as a Python script. This Python script would then be processed and C code generated which implemented a custom Apache module which wraps the script and hooks into Apache only in spots required. The C code would be compiled of course and you have your self contained Apache module. This would be to the extent that the top level hook functions where code included in the script file, would be embedded into the compiled Apache module, either as source code which is reinterpreted or as byte code. End result is single .so which is self contained for simple case, but could still import Python modules from installation to do stuff if more complicated things needed. This would provide a module which is efficient as far as overhead of hooking as only hooking what is required. Would allow Python code to implement custom Apache configuration directives specifically for the module. Would allow stating order of hooks within a phase relative to another Apache module. In summary, these generic hooking modules for scripting languages are more kludge than anything else. Lets get back to being able to write full Apache modules as they are intended. In some respects, what mod_wsgi itself does for embedded mode could be implemented using such a module generator. Note, there may be aspects of mod_perl which allow something similar, not sure of exact details of what it does. 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.
