On 04 December 2000, Neil Schemenauer said:
> Perhaps Quixote should get the configuration information from the
> application namespace.  The only remaining piece of configuration
> data is the root namespace itself which could be set by the cgi
> script:

There are several reasons I don't like that approach.  I think it boils
down to this: configuration info is integral to an application, but
should not (generally) be part of the application's source code.
External config files are a good thing -- it lets you tweak an
application without having to dive into the source code.

I think the fundamental problem with the quixote.config module is that
we were confused over what "the application" is.  It's not Quixote:
Quixote is a library that individual web applications use.  It's easy to
see how we got confused, because we are developing exactly one Quixote
application, which also happens to be a very large application that
would dwarf anything else we might put onto our web site.  In that
context, quixote.config makes some sense, although it's always had a few
warts (eg. the ROOT_PACKAGE variable referring to the "mems.ui" package,
which is information specific to *this application*).

When you want multiple Quixote applications running on the same web
site, though, the quixote.config module is not enough.  Each application
needs distinct configuration information.  However, it's quite likely
that multiple applications on the same site will share config info --
whether and where to mail tracebacks, whether to have "secure errors",
whether RUN_ONCE is true or not, etc.

But there are invariably differences between applications, and the root
namespace (aka the "root package") is the biggie.  Thus, I think we need
a place for common configuration information and application-specific
configuration information.

Neil's proposal was to put app-specific config info right into the
application's root namespace.  I don't like that, because it requires
tweaking the application's source code to tweak the configuration.
Also, what if you want to have two slightly different versions of an
application running on the same site?  If the differences can be
encapsulated in config variables -- eg. RUN_ONCE -- then it's easy; you
just need two config files (and possibly two FCGI/CGI scripts).

Finally, whatever we do, we need to make it dead easy for application
FCGI/CGI scripts to find and parse config files in order to generate
config objects they can pass to Quixote.

So here's a proposed API.  First, a Config class for Quixote (borrowing
syntax from a time-machine trip into Python's future ;-):

    class Config:
        decl root_namespace : string | module | instance
        decl url_prefix : string
        decl error_email : string
        decl debug_log : string
        # ... etc: one instance attribute for each variable currently
        # in the quixote.config module

        def read_file (filename):
            """Read configuration from a file.  Any variables already
            defined in this Config instance, but not in the file, are
            unchanged, so you can use this to build up a configuration
            by accumulating data from several config files.
            """

        def read_from_module (modname=None):
            """Read configuration info from a Python module (default
            is the module where the Config class is defined, ie.
            quixote.config).  Also accumulates config data, just like
            'read_file()'.
            """

Once this class is implemented, we'll have to go through the Quixote
source, purge all references to the "quixote.config" module, and pass
around a Config instance instead.

Then it's just a question of creating this Config instaince in the first
place, and passing it into Quixote from the application's FCGI/CGI
script.  Of course, the application could do it manually -- create a
Config object, 'read_file()' on it as many times as it likes, etc.

But I think there should be a standard convenience function in
quixote.init:

    def read_config (filename = None)

This would create a Config object and read config data from the
quixote.config module (or perhaps a separate default config file
installed somewhere other than Quixote's library directory).  Then, if
you supplied 'filename', it would read from that file.  That way, you
only have to put variables you want different from the default in your
application-specific config file.

Then dealing with config data is just one more line of boilerplate in a
simple Quixote app.  We go from

    init.install_imphooks()
    init.redirect_stdout()              # only with FastCGI (for now)
    session.set_session_manager(...)
    publish.call_fcgi()

to

    config = init.read_config()
    init.install_imphooks()
    init.redirect_stdout()              # only with FastCGI (for now)
    session.set_session_manager(...)
    publish.call_fcgi(config)

Or something like that -- the other init functions might need to grow
'config' arguments, not sure.

Sound reasonable?  Good, I'll get started right away.  ;-)

        Greg