[Web-SIG] WSGI and Configuration

[Phillip J. Eby]

At 11:53 PM 11/13/04 -0800, Robert Brewer wrote:
>  Phillip's idea about passing
>configs in a separate call seems like overkill to me--applications which
>are bare functions (not classes) will have to grow a wrapper to receive
>the configs, at the least.

My current proposal doesn't require this; instead, servers are asked to 
support importing *either* an application object or a setup object.

My main motivation for recommending that servers provide support for "setup 
objects" is that some existing apps/frameworks aren't really suited to a 
configuration-on-demand setup, and it's harder to write code to handle 
it.  So, applications that need setup can choose to be deployed that way, 
while still allowing users a "scriptless" deployment.

In any case, I consider "Scriptless Deployment" to be an optional WSGI 
extension anyway.  But, whatever we end up recommending, there will be 
support routines in wsgiref to make the server implementer's job easier.

One thought that occurs to me is that we *could* create a 
ConfigParser-based format to be a "deployment configuration" for an 
application.  It might contain a WSGI section that describes how to load 
and start the application, and any requirements such as threadability.  It 
could also contain server-specific configuration, such that an application 
developer could include recommended settings for different servers.  And 
the remaining sections would be for the application's use.  A reference to 
the loaded configuration object could be included in a 'wsgi.config' 
environment variable.

That's rather a lot to specify, but it would reduce the server-specific 
configuration format to be just mapping a URI location to a WSGI deployment 
file.  The rest could then be managed in the deployment file.