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