[Web-SIG] WSGI deployment use case

[Chris McDonough]

On Mon, 2005-07-25 at 20:29 -0500, Ian Bicking wrote:
> > We probably need something like a "site map" configuration, that can 
> > handle tree structure, and can specify pipelines on a per location 
> > basis, including the ability to specify pipeline components to be 
> > applied above everything under a certain URL pattern.  This is more or 
> > less the same as my "container API" concept, but we are a little closer 
> > to being able to think about such a thing.
> 
> It could also be something based on general matching rules, with some 
> notion of precedence and how the rule effects SCRIPT_NAME/PATH_INFO.  Or 
> something like that.
How much of this could be solved by using a web server's
directory/alias-mapping facility?

For instance, if you needed a single Apache webserver to support
multiple pipelines based on URL mapping, wouldn't it be possible in many
cases to compose that out of things like rewrite rules and script
aliases (the below assumes running them just as CGI scripts, obviously
it would be different with something using mod_python or what-have-you):

<VirtualHost *:80>
 ServerAdmin webmaster at plope.com
 ServerName plope.com
 ServerAlias plope.com
 ScriptAlias /viewcvs "/home/chrism/viewcvs.wsgi"
 ScriptAlias /blog "/home/chrism/blog.wsgi"
 RewriteEngine On
 RewriteRule ^/[^/]viewcvs*$ /home/chrism/viewcvs.wsgi [PT]
 RewriteRule ^/[^/]blog*$ /home/chrism/blog.wsgi [PT]
</VirtualHost>

Obviously it would mean some repetition in "wsgi" files if you needed to
repeat parts of a pipeline for each URL mapping.  But it does mean we
wouldn't need to invent more software.


> 
> > Of course, I still think it's something that can be added *after* having 
> > a basic deployment spec.
> 
> I feel a very strong need that this be resolved before settling on 
> anything deployment related.  Not necessarily as a standard, but 
> possibly as a set of practices.  Even a realistic and concrete use case 
> might be enough.


I *think* more complicated use cases may revolve around attempting to
use middleware as services that dynamize the pipeline instead of as
"oblivious" things.  I don't think there's anything really wrong with
that but I also don't think it can ever be specified with as much
clarity as what we've already got because IMHO it's a programming task.

I'm repeating myself, I'm sure, but I'm more apt to put a "service
manager" piece of middleware in the pipeline (or maybe just implement it
as a library) which would allow my endpoint app to use it to do
sessioning and auth and whatnot.  I realize that is essentially
"building a framework" (which is reviled lately) but since the endpoint
app needs to collaborate anyway, I don't see a better way to do it
except to rely completely on convention for service lookup (which is
what you seem to be struggling with in the later bits of your post).

- C