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.
_______________________________________________
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
