On 23:09 Tue 01 Feb , Ian Bicking wrote:
BTW, I have written a config parser with WSGIKit in mind, but I haven't plugged it into anything yet. I described some of the features here: http://blog.ianbicking.org/2005-01-wsgikit-config.html
I don't think we need a configuration parser in the tree at all. The easiest and most flexible solution is to simply import * from a .py config file. Think of it as a place to define environment variables.
Here's a quick example: TMDA is a mail filter that is is designed to work with individual UNIX accounts, but if I want to do virtual e-mail hosting I could extend it's delivery logic froms:
DELIVERY = "~/.maildir/"
to:
DELIVERY = "/home/vmail/%s/%s/" % (os.environ["HOST"], os.environ["USER"])
This expanded the functionality of this software not by re-writing or subclassing the tmda libraries, but by adding some brains to the configuration file itself.
True, to the degree that the software was written with this in mind. Because Webware isn't one-process-per-request it has to be more abstract. For instance, how would you dispatch on a virtual host in Webware? You could if you allowed for callable values, I suppose, like:
# normally:
#root = '/myapp/'
def root(trans):
return os.path.join('/myapp/vhost/',
trans.request().environ()['HTTP_HOST'])This isn't really possible with wsgikit.config; if this kind of per-host configuration was predicted you could do fixed locations like:
[vhost(app.number1.com)] root = /myapp/vhost/app.number1.com/
Or if you anticipated variable substitution you could do:
root = /myapp/vhost/${HTTP_HOST}/Allowing functions is quite interesting, and endears me more to Python files. It really makes it possible to support almost arbitrary hooks. Another thing I wanted to do was local configuration, so you could fold new files into the configuration based on path or something. E.g., put a .webware.conf file into a path and all URLs in that path would pick up that extra configuration. But that would still be possible with Python files.
One thing Python files aren't particularly good at is hierarchical configuration. You can create dictionaries, and they are okay. You can overload class statements, but then you have to support both dictionary and attribute access (or should everything be attribute-based?)
In some ways it bothers me because it's a bit complicated, but each point of complication is also a feature I think would be really useful, so it's hard to say.
Importing a file like config.py is simple if we think of it as a place
to define environment variables.
One nuisance is the importing process. Actually... not a huge nuisance. But I much prefer doing it through exec instead of import, because importing from arbitrary files is such a pain and has a lot of subtleties that just aren't necessary to introduce for this.
Part of me thinks that servlets and PSP files should work the same way, to avoid the ambiguity of file or packages.
The Webware application server is more complicated because it lists out the guts of a dictionary. Webware looks like this:
{ 'SessionStore': 'Dynamic', # can be File or Dynamic or Memory 'SessionTimeout': 180, # minutes 'MaxDynamicMemorySessions': 10000, # maximum sessions in memory }
I'm proposing this:
SESSION_STORE='Dynamic' # can be File or Dynamic or Memory SESSION_TIMEOUT=180 # minutes MAX_DYNAMIC_SESSIONS=1000 # maximum sessions in memory
Because this file has a .py extension the user knows the rules of the config file because it's python. This means of setting global parameters also also allows the user to define any site-specific parameters in the same file; such as:
DB_CONN='dbname=mydb user=fog'
BTW, CVS Webware does this as well; Configurable knows how to load Python files, and global variables become keys in the dictionary. (If the first character in the file is a { then it parsed the file the old way.) It's certainly much more readable and flexible than the dictionary approach.
You still need separate files for AppServer.config, Application.config, etc., but it's an improvement.
-- Ian Bicking / [EMAIL PROTECTED] / http://blog.ianbicking.org
------------------------------------------------------- This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting Tool for open source databases. Create drag-&-drop reports. Save time by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc. Download a FREE copy at http://www.intelliview.com/go/osdn_nl _______________________________________________ Webware-discuss mailing list Webware-discuss@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/webware-discuss
