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 [EMAIL PROTECTED] 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 _______________________________________________ Web-SIG mailing list Web-SIG@python.org Web SIG: http://www.python.org/sigs/web-sig Unsubscribe: http://mail.python.org/mailman/options/web-sig/archive%40mail-archive.com