[Web-SIG] WSGI configuration and character encoding.

[Ian Bicking]

Phillip J. Eby wrote:
> At 09:55 PM 11/30/04 -0600, Ian Bicking wrote:
> 
>> We aren't where (mindful) PHP is (or even close), but it's something 
>> to shoot for.  This may not actually apply to deployment configuration 
>> files, except that it would be nice if cooperative software could be 
>> packaged with a deployment configuration file that didn't need 
>> editing.  At which point it might as well be a Python script that sets 
>> up the necessary objects.  Python can be much smarter about this than 
>> any configuration file.
> 
> 
> Here's what I'm thinking: paths in the file should be allowed to be 
> relative to the directory containing the deployment file, and the 
> configuration passed to the application or its setup should include the 
> path to the deployment file.  The combination of these two things would 
> suffice to allow distribution of an application in a largely 
> ready-to-deploy form.  The application could always provide facilities 
> to edit its own configuration file(s) or the deployment configuration.

This leads to the question: when would you edit the deployment file? 
Besides just using a different directory prefix?

A given application has a fixed set of requirements, why not just code 
them up in Python?  Well, I can imagine reasons, but I think we need to 
start from use cases.

So here's a use case:

I have a Wiki application, written for Webware.  I can expose it at a 
few different levels -- the many Webware servlets (which are 
applications), or a single application, and that application can have 
more or less functionality (depending on how much functionality I expect 
the parent to have -- e.g., session support).

I also require configuration for the Wiki, though it probably could be 
installed with no configuration and reasonable defaults.  (Should it 
create a template configuration file with defaults in this case?  Where 
to put it?)

Because it is based on Webware (WSGIKit), it requires a bunch of 
middleware.  If there are other Webware applications in the stack, 
*maybe* it would be useful to share that middleware.  Maybe not, maybe 
just sharing configuration would be sufficient.

So, where does deployment fit in here?  Probably all you'd need would be 
to give the path to the application (maybe an importable package name), 
and an optional path to the configuration file for the application.  I 
don't need the configuration until runtime, though.

Or, it could be inverted.  The Wiki application is the front-facing 
object, and you tell it what server you want to use.  Both could even 
coexist fairly easily.  Maybe it would be smart enough to tell if it was 
being run as a CGI script (just by looking at the environment), and if 
not it would have options to start up some kind of server.  And it would 
export some conventional name, so you could point some other server at 
it, using whatever mechanisms that server uses (which probably includes 
giving the application a URL space).  As an application distributor this 
seems like the easiest thing to describe and support.

> This doesn't mean that some simple apps or middleware won't end up using 
> the deployment file for all their configuration needs, but that may well 
> be okay for their target audiences.  The key is to have a path to 
> near-turnkey installation, if possible.
> 
> 
>> Which is why I don't really think deployment configuration is all that 
>> important.  It doesn't hurt, but I don't think it should hold up the 
>> PEP in any way -- I think the PEP is entirely sufficient as it is, and 
>> we can figure out deployment or async or whatever in other PEPs, or in 
>> a later revision to WSGI.
> 
> 
> Hmm, I seem to recall you arguing almost the opposite about a year 
> ago...  ;)  For example, that it was really important for apps to know 
> what web server they were running in, and conversely that they expose 
> lots of configuration data to the web server.

Consistency is the hobgoblin of little minds!  Well, I don't know if 
I've been consistent or not, but I don't place much weight in it either 
way ;)

I guess I don't really want WSGI to be exposed to less-technical web 
developers, or to people who install applications based on it.  So I'd 
like the pieces to communicate with each other fairly freely and 
completely.  If we can automate something, that's great -- like 
including process information in the WSGI environment.  But 
configuration isn't automation, so it doesn't excite me a lot.

But of course configuration exists, so if it exists then I'd like to 
keep it together, because I find lots of configuration files to be hard 
to navigate (as a user).  I also want configuration to be optional, and 
deployment configuration isn't very optional.

-- 
Ian Bicking  /  ianb at colorstudy.com  /  http://blog.ianbicking.org