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 >
|