[mod_python] framework agnostics (was: Thread safety)

I guess where I am looking is beyond just the mod_python basics, and 
more into
what Apache has to offer as well. For example, its different request 
processing
phases, the ability to use mod_python as more than just the content 
handler
phase, the ability to work with other Python modules such as mod_ssl 
etc etc.
Because these things are very Apache specific, there isn't going to 
really
be an equivalent in some other HTTP server framework and thus WSGI 
can't really
encompass them in a portable way. Even some of the mod_python specific 
things
like support for automatic module reloading don't have parallels in 
other
systems. Thus as I said, WSGI has to either pitch quite low, or grow to 
implement
these things at the level of WSGI, in which case it becomes yet another 
framework
in itself, rather than just glue to bring together the HTTP server and 
a framework.

On 08/06/2005, at 1:43 PM, michael bayer wrote:

> This is interesting....Graham Dumpleton basically said that 
> environment-agnostic frameworks have to build down to the lowest 
> common denominator and therefore the developer loses most of the 
> "special" functionality you get with apache and mod_python, whereas 
> here you're saying the amount of framework-specific code should be 
> very minimal and therefore you could probably port your applications 
> to other frameworks quite easily.   Which is strange, both reasons are 
> seemingly in direct conflict with each other yet both have a lot of 
> truth to them.
>
> For my part, I think the WSGI interface is so minimalistic and open 
> ended that it probably could reveal the full featureset of mod_python 
> pretty straightforwardly, and if it were widely adopted you wouldnt 
> even have to port your application over between frameworks in most 
> cases, except for those portions that drill into the interface more 
> deeply for its special framework-specific features.
>
> I have a guy using my own "sub"-framework Myghty for his company's 
> website, and he actually moved his application from mod_python to 
> lighthttpd where he apparently gets much higher performance (havent 
> tried it myself), but none of his code had to change at all.  He just 
> moved from the ApacheHandler, which adapts to mod_python, to the 
> WSGIHandler, which adapts to lighthttpd via fast cgi, and started it 
> up.
>
> Myghty has started as pretty mod_python centric, but Im beginning to 
> think of ways to expose both the mod_python and the WSGI interfaces 
> depending on which one the application chooses to see, i.e. a function 
> declares itself as def handle(r), it gets the mod_python request or an 
> emulating object. if it declares itself as def handle(environ, 
> start_response) it gets the WSGI stuff.  Im not sure where im going 
> with that yet...though Im pretty inspired by the way Paste works by 
> stringing together all sorts of disparate WSGI components and im 
> feeling the urge to get more into that idea.
>
>
> On Jun 7, 2005, at 9:06 PM, Jorey Bump wrote:
>
>> mike bayer wrote:
>>
>>
>>> are any of those publishers framework-agnostic (i.e. work in other
>>> containers besides mod_python) ?   theres a great advantage to being 
>>> able
>>> to move an application over to other web environments, such as 
>>> standalone
>>> servers, lighttpd etc. either for performance testing or development.
>>>
>>
>> If you separate your core functionality properly, portability isn't 
>> much of an issue. Publishers and frameworks are best treated as 
>> simple interfaces to more complex code. Although it's possible to 
>> build entire applications with them, it's probably not a good idea.
>>
>> For example, I have a few packages that handle db routines, HTML 
>> generation, proprietary authentication systems, etc. These are too 
>> site-specific to be part of the standard library, but are essential 
>> to the work I do, so I keep them in my PYTHONPATH. As a result, my 
>> mod_python.publisher applications tend to be very small, and I 
>> suspect that I could easily reimplement them in Vampire, mpservlets, 
>> CGI, or even as standalone Python applications with embedded HTTP 
>> servers.
>>
>> More ambitious frameworks try to shield you from the development 
>> language entirely ("Edit your web site without any knowledge of 
>> HTML!") and should be considered as entirely proprietary. That's not 
>> a criticism, as it's usually the goal, but it's worth pointing out 
>> that it represents the furthest point of the spectrum. All ye who 
>> enter this land shall forsake portability. :)
>> _______________________________________________
>> Mod_python mailing list
>> Mod_python at modpython.org
>> http://mailman.modpython.org/mailman/listinfo/mod_python
>>
> _______________________________________________
> Mod_python mailing list
> Mod_python at modpython.org
> http://mailman.modpython.org/mailman/listinfo/mod_python