[mod_python] framework agnostics (was: Thread safety)

michael bayer mike_mp at zzzcomputing.com
Tue Jun 7 23:43:12 EDT 2005


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
>


More information about the Mod_python mailing list