Hi All,
Have there been any more developments off-list about the format of the
config file for WSGI deployment?
I'd like to apply the entry points labeling idea to sections in the
pipeline config file and propose the following extensions to the format.
Here is an example to start with:
[database: connection from database == 0.6.0]
host = 'mysqldb.pythonweb.org'
user = 'foo'
password = 'bar'
[connection from database == 0.6.0]
extra-non-standard-params = 'params'
[application: testApplication from web == 0.6.0]
message = 'Hello World!'
Each section represents the configuration of one piece of middleware as
before. Standard configuration sections are labeled and non-standard
extensions to standard sections use the same deployment string but with
no label so in the example extra-non-standard-params = 'params' is
considered a non-standard extension to database configuration.
This has three advantages:
1. Standardisation between similar WSGI middleware components becomes
easier because we could all agree to name standard database connection
parameters as database so middleware can be more interoperable.
Non-standard extensions can be named in a similar config section but
without the database label so that we define an extensible base standard.
2. Configuration can be accessed in code by name eg
config.get('database') or config.getAll('database') to get custom
extensions too. This means that whatever version of a package you are
using you can still refer to the correct configuration easily and also
use the configuration file in external scripts eg. to setup necessary
database tables etc without creating the full middleware chain.
3. It allows us to create a configuration hierarchy. I've written a WSGI
framework named Bricks http://www.pythonweb.org/bricks/ and the way it
works is to have a global config file for all applications at a site and
then a local config file if the application needs to override global
settings or provide extra middleware. The logic behind this is that
things like database connections are likely to be used by all
applications across a site and a new application you have installed from
a third party is not going to have the correct database settings so you
would want to use the settings defined in the global config file. Using
the new config file format we could simply say that if a global
configuration does not already have a named config section which appears
in a local config file then the local configuration is added below the
last piece of global configuration that matched (or at the end if no
matches were found).
We can also define an extension to this basic format: always include and
always exclude determined by a + or - sign just before the entry point
name so that we can also override global settings in a local config file
and provide a flexible configuration chain of as many config files as we
liked.
Here is an example to illustrate. We have an application which doesn't
need authorisation middleware but does need a session store. It needs a
database connection but is only capable of interacting with the one it
specifies, it also needs some configuration of its own. It is installed
on a site with other applications which use database, session and auth
middleware. The site administrator wants all applications to use GZip
encoded output.
global.wsgi:
[gzip: gzip from compression==0.1.0]
[database: connection from database== 0.6.0]
adapter = 'mysql'
database = 'test'
user = 'foo'
password = 'bar'
[auth: auth from database==0.6.0]
extra-non-standard-params = 'params'
[session: session from web==0.6.0]
params = 'interesting'
local.wsgi:
# Override any other database definitions
[+database: connection from database==0.6.0]
adapter = 'engine'
database = 'default'
# Define a session configuration to be use if no other is available
[session: session from web==0.6.0]
params = 'default'
[application: appSettings from app==0.1.0]
name = 'foo'
# The user installing the application wants to specifically
# exclude auth middleware since they know it isn't needed
[-auth]
If the global configuration file wasn't present, the application
configuration would look like this:
[database: connection from database==0.6.0]
adapter = 'engine'
database = 'default'
[session: session from web==0.6.0]
params = 'default'
[application: appSettings from app==0.1.0]
name = 'foo'
But when it is installed on a site with the global config file it looks
like this:
[gzip: gzip from compression==0.1.0]
[database: connection from database==0.6.0]
adapter = 'engine'
database = 'default'
[session: session from web==0.6.0]
params = 'interesting'
[application: appSettings from app==0.1.0]
name = 'foo'
So as you can see this allows a flexible deployment heirachy. What do
you think?
On a broader point I'd like to see pipeline configuration (what we are
talking about here) quite separate from the actual deployment details
such as where the application is going to be installed on a URL. I don't
think there is any need to standardise the latter as long as all
frameworks are capable of using the basic pipeline and deploying it in a
way they see fit, otherwise you start making the main application
configuration too framework-specific.
James
_______________________________________________
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
