[Web-SIG] A Python Web Application Package and Format

[Alice Bevan–McGregor]

On 2011-04-18 14:11:21 -0700, Daniel Holth said:

> The file format discussion seems utterly pointless.

That's a pity.

> If you want the format to specify cron jobs and services and non-wsgi 
> servers, why not go the whole way and use the Linux filesystem 
> hierarchy standard. The entry point is an executable called `init`, 
> configuration goes in /etc/, cron jobs go in /etc/cron.d etc. This 
> should be flexible enough.

Because that would be… less than good.  Let me illustrate:

a) The LFS is intended for complete operating system installations.

b) You sure as hell wouldn't want the init process to be Python.

c) Operating-system specific features are a no-go for portability.

d) We don't want developers to have to suddenly become sysadmins, too.

e) /etc is terrible for configuration organization.

There are other, lower-level reasons not to do that.

One big point is that the application server / container writes a 
single configuration file which is then read in by the application.  
One file, not a tree of them.

> I hope most applications won't need to look at the contents of app.yaml 
> (the application container config) at all.

No-one has said that an application /would/ have to look at the 
application metadata, or that after installation the file was anywhere 
app accessible, even.

> Paste Deploy configures logging by passing the .ini to logging before 
> invoking the app's entry point. This is the application container 
> configuring the logging.

I've already defined that.  RTFM or many ML messages about logging.

> For example a cool application container feature would be to have a 
> little web application that manipulated logging configuration in a 
> database, or reconfigured logging between requests without restarting 
> the application.

The former is already defined.  That's what the application server 
does, database or no.  The latter is broadly unnecessary, but easily 
implementable within the application you are deploying.

> One way to pass 'services' information would be to specify a support 
> package with abstract base classes and have a procedure for proposing 
> new standard services to the web-sig. The container would have to 
> populate a registry of named implementations of those services it is 
> able to support:

That seems… excessive and ugly.  You would also have code mixing 
between the application server level and application level which will 
encourage nothing but madness.  Simple, named services with optional 
configurations are more than enough.

> I would really like to see a basic specification with no support for 
> services or 'spending an hour running apt-get to reconfigure the server 
> before eventually getting around to running the application', and a 
> procedure for extending the format.

apt-get has already been thrown out, and was, in fact, never part of 
the quick summary I made, either.

	— Alice.