On Oct 23, 10:17 am, MilesTogoe <[EMAIL PROTECTED]> wrote:
> wmiller wrote:
> > On Oct 23, 2:17 am, "Graham Dumpleton" <[EMAIL PROTECTED]>
> > wrote:
>
> >> 2008/10/23 wmiller <[EMAIL PROTECTED]>:
>
> >>> just starting out with mod_wsgi on apache and I'm wondering, is it
> >>> less than ideal to have separate *.wsgi files for each URL versus just
> >>> one root *.wsgi file that parses and handles all the URLs for a
> >>> website?
>
> >>> In the sandbox environment I'm working in I have a separate *.wsgi
> >>> file for each URL because it's an easy way to get started. I'm
> >>> guessing for performance and resource reasons, it won't scale very
> >>> well - multiple Python interpretors running?
>
> >>> I'd prefer to avoid using frameworks or middleware and just stay as
> >>> low level and basic as possible, e.g. for each URL a simple file like
> >>> this with additional code/functionality depending on requirements:
>
> >>> def application(environ, start_response):
> >>> start_response('200 OK', [('content-type', 'text/html')])
> >>> HTML = "<html><body>%s</body></html>"
> >>> HTML %= "Hello world!"
> >>> return [HTML]
>
> >> There are a few issues here to consider.
>
> >> 1. The default of a separate sub interpreter per WSGI application will
> >> mean more overall memory use. Provided that the applications can
> >> coexist, this is easily solved by delegating them to all run in the
> >> same sub interpreter using the WSGIApplicationGroup. For example, to
> >> delegate them to run in the main Python interpreter (the first created
> >> by Python), use:
>
> >> WSGIApplicationGroup %{GLOBAL}
>
> >> Alternatively, if you have multiple sites, then use:
>
> >> WSGIApplicationGroup %{SERVER}
>
> >> This will mean that all WSGI scripts in that virtual host site would
> >> run in same sub interpreter.
>
> >> 2. Apache URL dispatch using file based resource matching, ie.,
> >> AddHandler and lots of .wsgi files, should be a lot faster than doing
> >> URL dispatch in Python code using Routes or some other Python based
> >> URL matcher.
>
> >> Apache also provides MultiViews matching allowing you to drop .wsgi
> >> extension in URLs, so URLs can still be clean.
>
> >> Although it can be a bit more complicated that a Python base URL
> >> routing solution, mod_rewrite rules can be used to do a lot of trick
> >> stuff with mapping path info back to GET style request parameters if
> >> you want to use REST style URL semantics, with segments of URLs
> >> becoming form input parameters.
>
> >> The Files directive in Apache also means you can do much finer grained
> >> control over the configuration of URLs than what a Python framework
> >> may allow easily.
>
> >> For example, you could set AcceptPathInfo to Off as default, and only
> >> set it to On for those resources which actually allow passing of path
> >> info.
>
> >> Similarly, the Limit method can be used default to only allow GET
> >> requests and then for specific resources allow over request methods as
> >> appropriate.
>
> >> Various frameworks don't filter either these things properly and any
> >> request method is possible with path info being able to be supplied
> >> even if not desired, with the latter then stuffing up relative links
> >> in pages.
>
> >> Other things that can be controlled on per resource basis is things
> >> like LimitRequestBody for POST requests.
>
> >> The resource approach also means you can mix WSGI scripts in the same
> >> directory as static media and not have to separate them out into a
> >> separate area. This allows everything to be localised with one
> >> directory potentially being a self contained application.
>
> >> All this acknowledges that Apache itself is a web application
> >> framework with a lot of power in its own right and not just a hopping
> >> off point to a pure Python world for your application. Personally I
> >> think Apache gets underutilised by Python people. When Apache 2.4
> >> comes out with mod_session and support for single sign on across
> >> applications this will be more evident.
>
> >> What would sort of be nice is if Python web application component
> >> providers would recognise that Apache has some good to offer rather
> >> than spurn it. In particular, it would be nice if Python auth/session
> >> mechanisms would provide a way of being used that is compatible with
> >> how mod_session works. This way one could use a Python session
> >> management mechanism if running Python standalone application, but
> >> then defer to mod_session in context of Apache, thereby allowing
> >> single sign on to work. Adopting the mod_session style interfacing
> >> method would also allow mix and match of Python components in a Python
> >> only application, whereas at the moment they all do things there own
> >> ways and come as monolithic solutions to the problem. If no one else
> >> sees this, and I have time, I'll probably end up bringing out my own
> >> auth/session components that work in this way as well as modify
> >> mod_wsgi to integrate in with mod_session so that Python code can acts
> >> as session store.
>
> >> 3. The low level nature of WSGI is also an issue and packages like
> >> Paste, WebOb and Werkzeug can help there if you want to work at that
> >> level.
>
> >> Overall I personally find working down at this Apache resource level
> >> with WSGI scripts for each major URL entry point of a single
> >> application quite attractive. This doesn't mean I wouldn't use some
> >> URL mapping in Python, but rather than using a really high level and
> >> potentially inefficient system like routes, I would use purpose built
> >> WSGI components for mapping that do a very specific job. That way they
> >> can be more efficient.
>
> >> I can't give examples right now as stuff I was playing with is on
> >> another machine. I also hadn't really had time to translate the stuff
> >> I was doing in this respect from mod_python to WSGI properly so its
> >> all a bit of a message and possibly not ready for public viewing.
>
> >> In some respects it comes down to personal tastes, like myself, some
> >> like tinkering at the lower levels in a more hands on approach, others
> >> prefer big frameworks which do a lot of stuff for you, but also
> >> potentially then put a straight jacket on you and force you to do
> >> things their way.
>
> >> Graham
>
> > and I was so close to giving up entirely on the low-level multi wsgi
> > file approach in favor of exclusively using middleware like Werkzeug.
>
> I guess I don't understand why. Assembler code is more low level than C
> but C is still low enough and gains you so much more productivity that
> few program at the assembler level any more - I think of Werkzeug as C
> in this analogy - it gives you so much but doesn't carry the often
> unnecessary baggage of higher level stuff.
mostly because using wsgi middleware and frameworks feels to me a
little like implementing a file system in a database instead of just
using the file system of the OS. Mapping URLs to files using Python
instead of using Apache is a good example of more moving parts, more
complexity, and less transparency. Because we're still using Python
to do the heavy lifting it's not as low level as it might seem.
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"modwsgi" group.
To post to this group, send email to modwsgi@googlegroups.com
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
-~----------~----~----~----~------~----~------~--~---
