From floydophone at gmail.com Tue Nov 2 22:08:50 2004 From: floydophone at gmail.com (Peter Hunt) Date: Tue Nov 2 22:08:58 2004 Subject: [Web-SIG] WebFlow early beta Message-ID: <6654eac404110213082f539ce7@mail.gmail.com> Check this out, look at the example (I didn't have time to build an interestign one)... http://misc.idyll.org/hunt-wsgi/webflow_wsgi.py Requires stackless. From ianb at colorstudy.com Fri Nov 12 00:11:26 2004 From: ianb at colorstudy.com (Ian Bicking) Date: Fri Nov 12 00:14:00 2004 Subject: [Web-SIG] WSGIKit / WSGI Webware Message-ID: <4193F19E.2070009@colorstudy.com> I've been doing some more work on WSGI Webware; I've now turned it into a package called wsgikit, with a distutils install, and generally a bit easier to work with. Most of the components are Webware-neutral, with fairly thin wrappers that implement the Webware API. While you can use it with Webware servlets, it should be possible to use it with other WSGI-enabled frameworks as well, coexisting peacefully. I'd be interested if anyone tries this; it might require some minor modifications to urlparser. Right now I'm including a couple servers with it -- notably Peter Hunt's Twisted server, which is functionally similar to Webware's AppServer -- but further on I'm hoping it will be easier to patch these two pieces together when distributed separately. Mostly it's a matter of convention and documentation. Anyway, just a note on progress. It's available at: svn://colorstudy.com/trunk/WSGIKit (this is a new location; renamed to WSGIKit from just WSGI) -- Ian Bicking / ianb@colorstudy.com / http://blog.ianbicking.org From ianb at colorstudy.com Sat Nov 13 00:03:51 2004 From: ianb at colorstudy.com (Ian Bicking) Date: Sat Nov 13 00:06:27 2004 Subject: [Web-SIG] WSGI and Configuration Message-ID: <41954157.1040502@colorstudy.com> Has anyone thought about what configuration might look like in a WSGI context? I'd like to set up some interface where configuration can be shared between frameworks. It's also important to me that configuration can be local in some fashion, not process- or installation-wide. For instance, override some configuration values for a specific URL hierarchy. Maybe the most obvious way would be something like environ['config.dict'], which would be a two-level dictionary (sections and keys), reminiscent of a .ini file. It might not be an actual dictionary, to more easily allow configurations to be layered and unlayered. But that's not very sophisticated, so I'm curious if anyone has any thoughts? I'm not too concerned with config file formats or anything; I'd like this to be neutral with respect to that (if that's possible, which I'm not sure), I'm mostly thinking about the API to the configuration at this point. -- Ian Bicking / ianb@colorstudy.com / http://blog.ianbicking.org From fumanchu at amor.org Sat Nov 13 00:17:00 2004 From: fumanchu at amor.org (Robert Brewer) Date: Sat Nov 13 00:18:28 2004 Subject: [Web-SIG] WSGI and Configuration Message-ID: <3A81C87DC164034AA4E2DDFE11D258E32451E7@exchange.hqamor.amorhq.net> Ian Bicking wrote: > Has anyone thought about what configuration might look like in a WSGI > context? I'd like to set up some interface where > configuration can be > shared between frameworks. It's also important to me that > configuration > can be local in some fashion, not process- or installation-wide. For > instance, override some configuration values for a specific > URL hierarchy. Given: Application <-> gateway <-> ... <-> gateway <-> server I can't think of any config data that would mean anything to any WSGI layer other than the application. Can you give an example of such? Robert Brewer MIS Amor Ministries fumanchu@amor.org From ianb at colorstudy.com Sat Nov 13 00:24:07 2004 From: ianb at colorstudy.com (Ian Bicking) Date: Sat Nov 13 00:26:44 2004 Subject: [Web-SIG] WSGI and Configuration In-Reply-To: <3A81C87DC164034AA4E2DDFE11D258E32451E7@exchange.hqamor.amorhq.net> References: <3A81C87DC164034AA4E2DDFE11D258E32451E7@exchange.hqamor.amorhq.net> Message-ID: <41954617.8010209@colorstudy.com> Robert Brewer wrote: > Ian Bicking wrote: > >>Has anyone thought about what configuration might look like in a WSGI >>context? I'd like to set up some interface where >>configuration can be >>shared between frameworks. It's also important to me that >>configuration >>can be local in some fashion, not process- or installation-wide. For >>instance, override some configuration values for a specific >>URL hierarchy. > > > Given: Application <-> gateway <-> ... <-> gateway <-> server > > I can't think of any config data that would mean anything to any WSGI > layer other than the application. Can you give an example of such? Well, sure. WSGIKit implements a lot of the pieces as middleware, and most of them could use some configuration. Right now that configuration is in the constructor (i.e., keyword arguments to the middleware). For instance URL Parsing is middleware. You tell the URL parser where to look for applications, and it delegates to the application it finds. It needs configuration to tell it where to look, how to map extensions, what files are private, etc. Sessions are also middleware, and obviously could use some configuration. One thing I'm dealing with now is the notion of an application root and working directory (since Webware has these notions, but WSGI doesn't); those will probably end up being configuration values. Hmm... but now I'm feeling confused about it. I'd like the session middleware to adopt configuration as it is defined when the session is used (which may be later than when the middleware is first invoked). So I don't know how that fits into it all. -- Ian Bicking / ianb@colorstudy.com / http://blog.ianbicking.org From pje at telecommunity.com Sat Nov 13 00:42:09 2004 From: pje at telecommunity.com (Phillip J. Eby) Date: Sat Nov 13 00:41:22 2004 Subject: [Web-SIG] WSGI and Configuration In-Reply-To: <41954157.1040502@colorstudy.com> Message-ID: <5.1.1.6.0.20041112182640.04243ec0@mail.telecommunity.com> At 05:03 PM 11/12/04 -0600, Ian Bicking wrote: >Has anyone thought about what configuration might look like in a WSGI >context? I'd like to set up some interface where configuration can be >shared between frameworks. It's also important to me that configuration >can be local in some fashion, not process- or installation-wide. For >instance, override some configuration values for a specific URL hierarchy. I don't know if this is what you're talking about, but the most basic form of configuration that every WSGI server/gateway *should* support is simple key-value pairs in 'environ'. For example, a Zope X3 WSGI application might want a 'ZOPE_SITE_CONFIG' environ variable to tell it where its configuration file is. In the simplest case for monolithic servers, this can be set as an OS-level environment variable. For more complex servers, this can be server configuration-driven. (E.g. Apache configuration files can set environment variables per path.) So, the simplest approach for apps is to receive this sort of per-instance deployment configuration is via an 'environ' variable, and server/gateway implementers are urged to allow per-instance settings of these variables. >Maybe the most obvious way would be something like environ['config.dict'], >which would be a two-level dictionary (sections and keys), reminiscent of >a .ini file. It might not be an actual dictionary, to more easily allow >configurations to be layered and unlayered. > >But that's not very sophisticated, so I'm curious if anyone has any thoughts? Heh. It's more sophisticated than what I'm suggesting, but I think maybe we have different use cases here. I'm seeking to support the diverse existing configuration formats that applications and frameworks "in the wild" already have, in a way that leans towards putting that configuration in the server setup, while minimizing the scripting needed for deployment. Actually, I think there are now starting to be enough deployment examples to maybe add a "Deployment Recommendations" section to the PEP. It seems to me that the best practice at this point is: * Application developer should supply their application as an importable object, and specify what configuration variables it requires. * Servers/gateways should support specifying either a source file+name, or module+name, to obtain the application * Servers/gateways should support specifying name+value string pairs to configure the aforementioned application. Each application instance should be able to have its own configuration, even if the actual application callable is the same object. Alternatively, I wonder if perhaps there should be an "application setup" importable, that gets passed the configuration, and returns the application? This would be useful for applications that want to do some initial setup, and don't want to have to write a bunch of code to manage configuration caching. From ianb at colorstudy.com Sat Nov 13 06:52:41 2004 From: ianb at colorstudy.com (Ian Bicking) Date: Sat Nov 13 01:52:32 2004 Subject: [Web-SIG] WSGI and Configuration In-Reply-To: <5.1.1.6.0.20041112182640.04243ec0@mail.telecommunity.com> References: <5.1.1.6.0.20041112182640.04243ec0@mail.telecommunity.com> Message-ID: <4195A129.1030405@colorstudy.com> Phillip J. Eby wrote: > At 05:03 PM 11/12/04 -0600, Ian Bicking wrote: > >> Has anyone thought about what configuration might look like in a WSGI >> context? I'd like to set up some interface where configuration can be >> shared between frameworks. It's also important to me that >> configuration can be local in some fashion, not process- or >> installation-wide. For instance, override some configuration values >> for a specific URL hierarchy. > > > I don't know if this is what you're talking about, but the most basic > form of configuration that every WSGI server/gateway *should* support is > simple key-value pairs in 'environ'. For example, a Zope X3 WSGI > application might want a 'ZOPE_SITE_CONFIG' environ variable to tell it > where its configuration file is. In the simplest case for monolithic > servers, this can be set as an OS-level environment variable. For more > complex servers, this can be server configuration-driven. (E.g. Apache > configuration files can set environment variables per path.) > > So, the simplest approach for apps is to receive this sort of > per-instance deployment configuration is via an 'environ' variable, and > server/gateway implementers are urged to allow per-instance settings of > these variables. In this model, each dispatching middleware should have a way to indicate environmental variables that should be added to each request. This would be something like wsgikit.urlparser, but also twisted_wsgi.WSGIResource, and potentially others. Or a little piece of middleware like: def environ_changer(application, environ_updates): def environ_application(environ, start_response): environ.update(environ_updates) return application(environ, start_response) Though these little middlewares can get out of hand. >> Maybe the most obvious way would be something like >> environ['config.dict'], which would be a two-level dictionary >> (sections and keys), reminiscent of a .ini file. It might not be an >> actual dictionary, to more easily allow configurations to be layered >> and unlayered. >> >> But that's not very sophisticated, so I'm curious if anyone has any >> thoughts? > > > Heh. It's more sophisticated than what I'm suggesting, but I think > maybe we have different use cases here. I'm seeking to support the > diverse existing configuration formats that applications and frameworks > "in the wild" already have, in a way that leans towards putting that > configuration in the server setup, while minimizing the scripting needed > for deployment. I can certainly see that need as well, though you can kind of do that in an ad hoc way, with stuff like environ.get('ZOPE_SITE_CONF', os.environ.get('ZOPE_SITE_CONF')). But with WSGIKit I'm not entirely trying to support Webware seemlessly; there's a bunch of crufty configuration and file layout parts that I'd rather get rid of. And I'm trying to keep it Webware-neutral; both so other frameworks can work under the middleware I'm making, and so Webware can work under other middleware that works like mine does. So I'm hoping for concensus of some sort. > Actually, I think there are now starting to be enough deployment > examples to maybe add a "Deployment Recommendations" section to the > PEP. It seems to me that the best practice at this point is: > > * Application developer should supply their application as an importable > object, and specify what configuration variables it requires. Sounds good. "Importable" is a pain. I think most web frameworks have to deal with the annoyances of importing arbitrary files, which is crufy in Python and has all sorts of annoying corner cases. Maybe we can solve that more cleanly while we're at it? Maybe as part of wsgiref, maybe pulling out the importing stuff you have in PEAK. wsgikit.urlparser.load_module has one implementation, but I know it's sub-optimal. In some models of URL resolution, like Apache, there's no relation of files to sys.path or any importable name. Webware just creates fake names in that case. In any case relative imports are all funky. Anyway, I'd love to have a solid solution to those issues. But that's kind of an aside. > * Servers/gateways should support specifying either a source file+name, > or module+name, to obtain the application > > * Servers/gateways should support specifying name+value string pairs to > configure the aforementioned application. Each application instance > should be able to have its own configuration, even if the actual > application callable is the same object. Definitely need this, and this is part of what I'm thinking of for configuration. In WSGIKit I edited Peter's Twisted server a bit to make it runnable as a script. But I had to hardcode webkit into it, since webkit isn't functional without at least minimal configuration (indicating a base path). That's actually not too bad, because wsgikit.webkit.wsgiwebkit.webkit (ack, bad name...) is actually fairly Webware-neutral as well, so hardcoding it in doesn't make this Webware-specific. Well, thinking further, this is where I'd rather not expose certain parts to the typical user. I kind of like that webkit is hard coded into the Twisted server I distribute with WSGIKit. That's one less thing that users have to think about. If I wasn't keeping a copy of twisted_wsgi, I'd probably create a small script that plugged them together, but I'd want to do that instead of just giving instructions on how to use the command line. So providing a standard command-line API maybe isn't that interesting. Really I want to insulate users from WSGI; I don't think they should know about it unless they want to work on the framework itself. I want really minimal instructions, like: * dump your files in a directory (Webware servets, Spyce pages, whatever). * Run this server, pointing it to aforementioned directory. Voila! Oh, and pass in some configuration file, which hopefully is general enough that it can encompass Webware, Spyce, and all the other high-level frameworks, and the low-level pieces that come along for the ride. > Alternatively, I wonder if perhaps there should be an "application > setup" importable, that gets passed the configuration, and returns the > application? This would be useful for applications that want to do some > initial setup, and don't want to have to write a bunch of code to manage > configuration caching. In this case, I think the person can create a script that invokes both server and sets up the application. I guess. I'm actively changing my mind on what I want, so if I'm inconsistent... -- Ian Bicking / ianb@colorstudy.com / http://blog.ianbicking.org From pje at telecommunity.com Sat Nov 13 03:55:29 2004 From: pje at telecommunity.com (Phillip J. Eby) Date: Sat Nov 13 03:54:45 2004 Subject: [Web-SIG] WSGI and Configuration In-Reply-To: <4195A129.1030405@colorstudy.com> References: <5.1.1.6.0.20041112182640.04243ec0@mail.telecommunity.com> <5.1.1.6.0.20041112182640.04243ec0@mail.telecommunity.com> Message-ID: <5.1.1.6.0.20041112214125.020e68b0@mail.telecommunity.com> At 11:52 PM 11/12/04 -0600, Ian Bicking wrote: >I can certainly see that need as well, though you can kind of do that in >an ad hoc way, with stuff like environ.get('ZOPE_SITE_CONF', >os.environ.get('ZOPE_SITE_CONF')). Yep. >>Actually, I think there are now starting to be enough deployment examples >>to maybe add a "Deployment Recommendations" section to the PEP. It seems >>to me that the best practice at this point is: >>* Application developer should supply their application as an importable >>object, and specify what configuration variables it requires. > >Sounds good. "Importable" is a pain. I think most web frameworks have to >deal with the annoyances of importing arbitrary files, which is crufy in >Python and has all sorts of annoying corner cases. Maybe we can solve >that more cleanly while we're at it? Maybe as part of wsgiref, maybe >pulling out the importing stuff you have in PEAK. >wsgikit.urlparser.load_module has one implementation, but I know it's >sub-optimal. In some models of URL resolution, like Apache, there's no >relation of files to sys.path or any importable name. Webware just >creates fake names in that case. In any case relative imports are all >funky. Anyway, I'd love to have a solid solution to those issues. But >that's kind of an aside. *Shudder*. Ideally, a server would allow customizing sys.path at least long enough to import/setup the application. Otherwise, we lose out on being able to e.g. deploy an application in a zipfile. (Wouldn't that be nice?) I don't think PEAK's import tools really have much to offer here, unless you just mean the convenient 'importString()' function. Couple that with maybe some temporary additions to sys.path, and you're set. Of course, of the Python web servers out there, I'm thinking only mod_python and modjy are really going to be able to handle this well. mod_python can run apps in separate interpreters, and each can have its own, completely transparent sys.path. modjy uses Jython, so in principle it could run apps in different interpreters, though I don't think it currently does. I *do* have a project on the back burner to make the CPython multi-interpreter API accessible from Python code, though. Indeed, I intend to write a PEP to propose standardizing a multi-interpreter API for CPython, Jython, IronPython, and indeed all Python implementations. But first, I'd like to finalize PEP 333. :) >>Alternatively, I wonder if perhaps there should be an "application setup" >>importable, that gets passed the configuration, and returns the >>application? This would be useful for applications that want to do some >>initial setup, and don't want to have to write a bunch of code to manage >>configuration caching. > >In this case, I think the person can create a script that invokes both >server and sets up the application. I guess. > >I'm actively changing my mind on what I want, so if I'm inconsistent... I noticed that. :) Anyway, the "app setup" idea was to get things to the point that, in principle, the user would only have to edit configuration files to deploy a WSGI application. They shouldn't have to write scripts just to run an application. Even for middleware stack management, if each piece of middleware had a configuration variable to specify what its downstream app-setup call was, you could create the whole thing from server config, as long as you had only one instance of a given kind of middleware per stack. Anyway, in an ideal world, you shouldn't have to edit the application itself, only its config file(s). And the application should find out its config file(s) from the server. Then, the application code is reusable to deploy multiple copies of the app. If you can't do that, then the user has to write a script for each deployed instance. From fumanchu at amor.org Sat Nov 13 07:19:37 2004 From: fumanchu at amor.org (Robert Brewer) Date: Sat Nov 13 07:21:06 2004 Subject: [Web-SIG] WSGI and Configuration Message-ID: <3A81C87DC164034AA4E2DDFE11D258E32451E8@exchange.hqamor.amorhq.net> Phillip J. Eby wrote: > Anyway, the "app setup" idea was to get things to the > point that, in principle, the user would only have to edit > configuration files to deploy a WSGI application. > They shouldn't have to write scripts > just to run an application. Even for middleware stack > management, if each piece of middleware had a > configuration variable to specify what its > downstream app-setup call was, you could create the whole > thing from server config, as long as you had only > one instance of a given kind of middleware per stack. > > Anyway, in an ideal world, you shouldn't have to edit the application > itself, only its config file(s). And the application should > find out its config file(s) from the server. Then, the > application code is reusable to deploy multiple copies > of the app. If you can't do that, then the user has > to write a script for each deployed instance. Although I agree (and designed my framework that way), I know not every framework author thinks that way. At the least, won't some apps expect a single mapping, some apps expect ConfigParser sections (multiple peer dictionaries), and some full XML-style trees? Sounds like you're describing the second of those (which I also use). And some developers even prefer deployers to write Python scripts, it would seem. Meh. I'm just speculating that specifying this within WSGI could hurt its adoption more than help. If we chose to force XML adoption, for example, I'd be unhappy. But I'm willing to be convinced otherwise. ;) It'd be fabulous to standardize. Robert Brewer MIS Amor Ministries fumanchu@amor.org From pje at telecommunity.com Sat Nov 13 07:55:56 2004 From: pje at telecommunity.com (Phillip J. Eby) Date: Sat Nov 13 07:55:15 2004 Subject: [Web-SIG] WSGI and Configuration In-Reply-To: <3A81C87DC164034AA4E2DDFE11D258E32451E8@exchange.hqamor.amo rhq.net> Message-ID: <5.1.1.6.0.20041113015218.02574ec0@mail.telecommunity.com> At 10:19 PM 11/12/04 -0800, Robert Brewer wrote: >Although I agree (and designed my framework that way), I know not every >framework author thinks that way. At the least, won't some apps expect a >single mapping, some apps expect ConfigParser sections (multiple peer >dictionaries), and some full XML-style trees? Sounds like you're >describing the second of those (which I also use). And some developers >even prefer deployers to write Python scripts, it would seem. > >Meh. I'm just speculating that specifying this within WSGI could hurt >its adoption more than help. If we chose to force XML adoption, for >example, I'd be unhappy. But I'm willing to be convinced otherwise. ;) >It'd be fabulous to standardize. I'm suggesting that we have deployment "recommendations", not requirements. Also, keep in mind that *all* of the variations you describe are nonetheless possible within the scope of my proposed approach. For example, if an application takes a configuration parameter that is the name of a Python script, XML file, configparser file, etc. The thing is, most applications or frameworks of any signficant scope already have some mechanism for keeping at least *some* of their configuration separate from code, even if the configuration is accomplished using a "configuration file" that is a Python script that just sets a bunch of variables. So, most should be able to easily work within the "recommended" deployment approach. (Assuming that we agree on one.) From floydophone at gmail.com Sat Nov 13 15:51:07 2004 From: floydophone at gmail.com (Peter Hunt) Date: Sat Nov 13 15:51:11 2004 Subject: [Web-SIG] Re: WSGI and Configuration Message-ID: <6654eac404111306515e443879@mail.gmail.com> Why don't we just let each middleware/gateway/application handle configuration by itself? Sure, it's a pain, but it's the defacto way to do it. The other option I see would be inventing something similar to JNDI... From py-web-sig at xhaus.com Sat Nov 13 16:28:38 2004 From: py-web-sig at xhaus.com (Alan Kennedy) Date: Sat Nov 13 16:26:45 2004 Subject: [Web-SIG] WSGI and Configuration In-Reply-To: <5.1.1.6.0.20041112214125.020e68b0@mail.telecommunity.com> References: <5.1.1.6.0.20041112182640.04243ec0@mail.telecommunity.com> <5.1.1.6.0.20041112182640.04243ec0@mail.telecommunity.com> <5.1.1.6.0.20041112214125.020e68b0@mail.telecommunity.com> Message-ID: <41962826.3090301@xhaus.com> [Phillip J. Eby] > *Shudder*. Ideally, a server would allow customizing sys.path at > least long enough to import/setup the application. Otherwise, we lose > out on being able to e.g. deploy an application in a zipfile. > (Wouldn't that be nice?) Very nice. It would be great to just drop a zipfile containing all code and support resources into a single configured location, j2ee-war-style. This would be a *huge* boon to simplifying deployment. WSGI presents many opportunities for simplifying server admin, and IMHO we should take advantage of as many as possible. > I don't think PEAK's import tools really have much to offer here, > unless you just mean the convenient 'importString()' function. > Couple that with maybe some temporary additions to sys.path, and > you're set. > > Of course, of the Python web servers out there, I'm thinking only > mod_python and modjy are really going to be able to handle this well. > mod_python can run apps in separate interpreters, and each can have its > own, completely transparent sys.path. modjy uses Jython, so in > principle it could run apps in different interpreters, though I don't > think it currently does. Currently modjy doesn't support multiple interpreters, since I recoded it in jython for prototyping simplicity. When I port (some of) it back to java, it is straightforward to support multiple interpreters. At the moment, due to time constraints on my part, modjy is basically in "follow mode": i.e. I will implement extras for it as and when clear concensus emerges on issues. But I can already see that modjy's naive import mechanism is soon going to become a hindrance. I'd really appreciate some pointers to clear guidance/reading-material on the full range of issues that can arise with imports, if anyone knows of such? Pointers to good (i.e. well structured and well documented) code that handles imports would be a good second-best. > I *do* have a project on the back burner to make the CPython > multi-interpreter API accessible from Python code, though. Indeed, I > intend to write a PEP to propose standardizing a multi-interpreter API > for CPython, Jython, IronPython, and indeed all Python implementations. +0 > But first, I'd like to finalize PEP 333. :) +1 > Anyway, in an ideal world, you shouldn't have to edit the application > itself, only its config file(s). And the application should find out > its config file(s) from the server. Then, the application code is > reusable to deploy multiple copies of the app. If you can't do that, > then the user has to write a script for each deployed instance. +1 IMO, we should strive for that ideal world, because we can. We have a golden opportunity, right here, right now: the python world is watching WSGI, and the python world seems to be growing larger and larger by the week. regards, Alan. From py-web-sig at xhaus.com Sat Nov 13 17:05:20 2004 From: py-web-sig at xhaus.com (Alan Kennedy) Date: Sat Nov 13 17:03:31 2004 Subject: [Web-SIG] Re: WSGI and Configuration In-Reply-To: <6654eac404111306515e443879@mail.gmail.com> References: <6654eac404111306515e443879@mail.gmail.com> Message-ID: <419630C0.3010602@xhaus.com> [Peter Hunt] > Why don't we just let each middleware/gateway/application handle > configuration by itself? Sure, it's a pain, but it's the defacto way > to do it. I disagree. If we permit "the market" to decide its preferred form of configuration, we're going to end up with a babel of configuration file formats. For example, say that the convention is to configure middleware through server/gateway configuration files. Authors of WSGI middleware would then have to document how to configure their component in several different configuration languages, each of which have subtly different quoting, escaping, encoding, etc, issues, for example: Apache httpd.conf markup language vs. XML (j2ee, etc) If the convention is for middleware to decide its own configuration format, then building and configuring middleware stacks could potentially be an exercise in frustration, maintaining configuration across several formats. So now the middleware authors job is easy, at the expense of the administrator who now has to maintain a set of configurations files like this middle1.ini middle2.xml middle3.py middle4.pth middle5.yaml middle6.etc middle7.etc2 IMHO, we should state some simple requirements for how we would like configuration to be handled. Here is an idea of the type of thing I mean 1. In order to reduce the documentation workload on middleware and framework authors, it is desirable to have a single configuration language which is supported in all WSGI environments. 2. In order to simplify the task of WSGI server administrators, it is desirable that the configuration of an entire middleware stack be storable in a single file/hierarchy of nested/include files. 3. In order to maximise internationalization opportunities, the chosen configuration mechanism should support the widest possible range of character encodings, and it should be easy for the user to explicitly specify the encoding. On the latter point, I believe we need to discourage ascii-centrism and encourage unicode-awareness. More international dialogue! ;-) [Peter Hunt] > The other option I see would be inventing something similar to JNDI... Well, I think that 99% of the time, configuration consists of just a list of name/value pairs, although the value can obviously have complex structure. Given that dynamically building data structures is where python really shines, it should be possible to come up with something flexible and powerful enough to cover the vast majority of situations. I'm perhaps being a little strident now ;-), but I think we should address the character encodings issues head-on, and eliminate any possible configuration technology that doesn't support easy handling of character encodings. Which leaves python (PEP 263) and XML () top of my list. Kind regards, al?in ? cinn?ide From fumanchu at amor.org Sat Nov 13 18:52:03 2004 From: fumanchu at amor.org (Robert Brewer) Date: Sat Nov 13 18:53:33 2004 Subject: [Web-SIG] Re: WSGI and Configuration Message-ID: <3A81C87DC164034AA4E2DDFE11D258E32451EE@exchange.hqamor.amorhq.net> Alan Kennedy wrote: > Well, I think that 99% of the time, configuration consists of just a > list of name/value pairs, although the value can obviously have complex > structure. Given that dynamically building data structures is where > python really shines, it should be possible to come up with something > flexible and powerful enough to cover the vast majority of situations. In my experience, that 99% can be served by: environ["myapp.config"] = {'branch1': {'leaf1': 'value1', 'leaf2': 'value2',}, 'branch2': {'leafA': 'valueA'}, } That is, a dictionary of dictionaries of strings. Using PEAK's importString() function or my xray.py*, anything more complex can be dynamically imported given a string value. This happens to correspond nicely to ConfigParser, where branches are "sections" and leaves are k/v pairs. Or we could make all of our deployers learn yaml. Or a new wsgiml. Yuck. Robert Brewer MIS Amor Ministries fumanchu@amor.org * http://www.aminus.org/rbre/python/xray.py From pje at telecommunity.com Sat Nov 13 18:57:46 2004 From: pje at telecommunity.com (Phillip J. Eby) Date: Sat Nov 13 18:57:06 2004 Subject: [Web-SIG] Re: WSGI and Configuration In-Reply-To: <419630C0.3010602@xhaus.com> References: <6654eac404111306515e443879@mail.gmail.com> <6654eac404111306515e443879@mail.gmail.com> Message-ID: <5.1.1.6.0.20041113124543.0322de80@mail.telecommunity.com> At 04:05 PM 11/13/04 +0000, Alan Kennedy wrote: >[Peter Hunt] > > Why don't we just let each middleware/gateway/application handle > > configuration by itself? Sure, it's a pain, but it's the defacto way > > to do it. > >I disagree. > >If we permit "the market" to decide its preferred form of configuration, >we're going to end up with a babel of configuration file formats. This babel you speak of, already exists. It's not WSGI's job to force applications -- or servers -- into a single configuration format. OTOH, I do believe that *deployment* configuration (i.e. telling apps or middleware where to *find* their configuration) is an appropriate responsibility of a WSGI server, and that having a standard way to get that information from the server to the app is an appropriate goal for the spec. >For example, say that the convention is to configure middleware through >server/gateway configuration files. Authors of WSGI middleware would then >have to document how to configure their component in several different >configuration languages, each of which have subtly different quoting, >escaping, encoding, etc, issues, for example: Apache httpd.conf markup >language vs. XML (j2ee, etc) I think you're making this more complicated than it is. Do Java application authors have to document every web server's configuration, or do they say, "here's the servlets, these are their options, see your server's doc for how to deploy them"? ISTM that it's sufficient to say, "I'm a WSGI application, this is the module or file with my application object, and I need a path to my configuration file in the variable FOOBAR_CONFIG. See your server's documentation for how to deploy me." >IMHO, we should state some simple requirements for how we would like >configuration to be handled. Here is an idea of the type of thing I mean > >1. In order to reduce the documentation workload on middleware and >framework authors, it is desirable to have a single configuration language >which is supported in all WSGI environments. > >2. In order to simplify the task of WSGI server administrators, it is >desirable that the configuration of an entire middleware stack be storable >in a single file/hierarchy of nested/include files. > >3. In order to maximise internationalization opportunities, the chosen >configuration mechanism should support the widest possible range of >character encodings, and it should be easy for the user to explicitly >specify the encoding. > >On the latter point, I believe we need to discourage ascii-centrism and >encourage unicode-awareness. More international dialogue! ;-) This goes a bit farther than I think is practical. Servers, gateways and applications already exist, and they are not reasonably going to change their configuration formats. The *only* place where trying to standardize configuration would even be *possible* is middleware, because before PEP 333, no WSGI middleware existed by definition. However, I personally don't see how any such standardization is *practical*, unless the mechanism itself is Python-based. For example, writing a Python script to stack a bunch of middleware, configuring it in the process. But even for that, I think we need to see more specific use cases for what these middleware stacks are going to *do*, because right now we (or at least I) don't even know enough about their requirements to be able to do meaningful design. From pje at telecommunity.com Sat Nov 13 19:30:10 2004 From: pje at telecommunity.com (Phillip J. Eby) Date: Sat Nov 13 19:29:31 2004 Subject: [Web-SIG] Re: WSGI and Configuration In-Reply-To: <3A81C87DC164034AA4E2DDFE11D258E32451EE@exchange.hqamor.amo rhq.net> Message-ID: <5.1.1.6.0.20041113131554.026a5cc0@mail.telecommunity.com> At 09:52 AM 11/13/04 -0800, Robert Brewer wrote: >Alan Kennedy wrote: > > Well, I think that 99% of the time, configuration consists of just a > > list of name/value pairs, although the value can obviously have >complex > > structure. Given that dynamically building data structures is where > > python really shines, it should be possible to come up with something > > flexible and powerful enough to cover the vast majority of situations. > >In my experience, that 99% can be served by: > >environ["myapp.config"] = > {'branch1': {'leaf1': 'value1', > 'leaf2': 'value2',}, > 'branch2': {'leafA': 'valueA'}, > } Which can also be rendered in flat form as: myapp.config.branch1.leaf1 = value1 myapp.config.branch1.leaf2 = value2 myapp.config.branch1.leaf1 = value1 myapp.config.branch2.leafA = valueA Which can be done with simple key=string configuration settings. My current preference for the deployment standard is: * Servers should allow you to specify an "application import" or a "setup import" * Servers should allow you to specify a small number of short key/value configuration strings An "import" is a combination of either PYTHONPATH+module or a Python filename, plus the name of an object to be obtained from that module or file. An "application import" is an "import" that designates an actual WSGI application object (in which case the config data goes in its environ on each call). A "setup import" is an "import" that designates a callable that should be invoked with a configuration mapping, to obtain the application object. It could be used like this: def setup_my_app(options): return MyAppClass(**options) or this: def setup_my_app(options): return app_from_file(options['CONFIG_FILE']) or this: class Application: def __init__(self,options): self.load_config(options['CONFIG_FILE']) # etc. def __call__(self,environ,start_response): # app code here I would suggest that the configuration mapping should include WSGI-specific configuration variables like the multithread/multiprocess/run-once flags, and also any CGI variables that will be constant over the application's lifetime, such as SERVER_NAME, DOCUMENT_ROOT, etc. From ianb at colorstudy.com Sun Nov 14 12:47:33 2004 From: ianb at colorstudy.com (Ian Bicking) Date: Sun Nov 14 07:47:21 2004 Subject: [Web-SIG] WSGI and Configuration In-Reply-To: <3A81C87DC164034AA4E2DDFE11D258E32451E8@exchange.hqamor.amorhq.net> References: <3A81C87DC164034AA4E2DDFE11D258E32451E8@exchange.hqamor.amorhq.net> Message-ID: <419745D5.8060806@colorstudy.com> Robert Brewer wrote: > Meh. I'm just speculating that specifying this within WSGI could hurt > its adoption more than help. If we chose to force XML adoption, for > example, I'd be unhappy. But I'm willing to be convinced otherwise. ;) > It'd be fabulous to standardize. I'm not looking for any standard, I'd just like some feedback on conventions. As we start poking things into the WSGI environment, it would be nice if we could agree on the API in there. At some future point, maybe it will seem reasonable to standardize that. I'm not even worried about configuration files at this point, though it's hard to ignore them entirely, as different file formats produce different output (e.g., .ini is fairly flat, vs. something like ZConfig or YAML which can be more structured). Anyway, maybe we can support multiple formats, or let the server load the configuration in whatever way it feels fit, or whatever. In regards to backward compatibility, I'm not too concerned about that. Rather I would hope frameworks in the future will use this convention, at least as an option. E.g., they could use an environmental variable, native configuration files, etc., but if they see configuration values in some agreed-upon location in the WSGI environ they'd use those as well (maybe with precedence, or maybe as a fallback). This way at least the user has a chance of keeping their configuration files under control. If they are already scattered about, then they can probably stay that way. -- Ian Bicking / ianb@colorstudy.com / http://blog.ianbicking.org From fumanchu at amor.org Sun Nov 14 08:53:50 2004 From: fumanchu at amor.org (Robert Brewer) Date: Sun Nov 14 08:55:20 2004 Subject: [Web-SIG] WSGI and Configuration Message-ID: <3A81C87DC164034AA4E2DDFE11D258E32451F3@exchange.hqamor.amorhq.net> Ian Bicking wrote: > Robert Brewer wrote: > > Meh. I'm just speculating that specifying this within WSGI > could hurt > > its adoption more than help. If we chose to force XML adoption, for > > example, I'd be unhappy. But I'm willing to be convinced > otherwise. ;) > > It'd be fabulous to standardize. > > I'm not looking for any standard, I'd just like some feedback on > conventions. As we start poking things into the WSGI environment, it > would be nice if we could agree on the API in there. At some future > point, maybe it will seem reasonable to standardize that. > > I'm not even worried about configuration files at this point, though > it's hard to ignore them entirely, as different file formats produce > different output (e.g., .ini is fairly flat, vs. something > like ZConfig or YAML which can be more structured). Anyway, maybe > we can support multiple formats, or let the server load the configuration > in whatever way it feels fit, or whatever. Sorry; I misunderstood. I thought it had already been determined that config data would go in environ['myapp.custom_data'] (or some other more meaningful dotted-name), so I figured you were looking to change that. Given that environ is already being passed in the standard through all layers, I don't see any reason to change. Phillip's idea about passing configs in a separate call seems like overkill to me--applications which are bare functions (not classes) will have to grow a wrapper to receive the configs, at the least. I think if we wrap one more callable in a callable, my head's going to implode; WSGI is already more complex than metaclasses ever were. Every server is going to provide different mechanisms for specifying single config options. If we stick to environ, they can provide that pretty straightforwardly (and in a manner specific to their server, so no convention is necessary). > In regards to backward compatibility, I'm not too concerned > about that. Nor am I. > Rather I would hope frameworks in the future will use this > convention, at least as an option. E.g., they could use an > environmental variable, native configuration files, etc., > but if they see configuration values in some agreed-upon > location in the WSGI environ they'd use those as > well (maybe with precedence, or maybe as a fallback). I don't see any problem with the PEP as it stands (the "Application Configuration" section). Middleware and apps can read the environ variables they care about. As the PEP says: "But, most existing applications and frameworks will probably only need a single configuration value from environ, to indicate the location of their application or framework-specific configuration file(s)." > This way at least the user has a chance of keeping their > configuration files under control. If they are already > scattered about, then they can probably stay that way. So you want them all in the same folder or file? I can't figure out exactly what concrete behavior you're trying to promote (or avoid). I'm getting lost in the rabbit holes. It seems to me there are at least five separate issues here: 1. How a given server populates wsgi environ dicts. 2. Dynamic imports from dotted package names. A minor issue, but recurring. 3. How to pass config data through a WSGI chain. In my mind, that's already specified: environ. 4. How to load and normalize complex config data from various sources: ini, xml, yaml, zconfig (heh, just noticed the "XYZ" acrostic ;). 5. How to minimize config file "spread" (?) Which are you addressing? Or am I still missing it completely (wouldn't be surprised)? Robert Brewer MIS Amor Ministries fumanchu@amor.org From ianb at colorstudy.com Sun Nov 14 14:14:34 2004 From: ianb at colorstudy.com (Ian Bicking) Date: Sun Nov 14 09:14:22 2004 Subject: [Web-SIG] WSGI and Configuration In-Reply-To: <3A81C87DC164034AA4E2DDFE11D258E32451F3@exchange.hqamor.amorhq.net> References: <3A81C87DC164034AA4E2DDFE11D258E32451F3@exchange.hqamor.amorhq.net> Message-ID: <41975A3A.9040203@colorstudy.com> Robert Brewer wrote: >>Rather I would hope frameworks in the future will use this >>convention, at least as an option. E.g., they could use an >>environmental variable, native configuration files, etc., >>but if they see configuration values in some agreed-upon >>location in the WSGI environ they'd use those as >>well (maybe with precedence, or maybe as a fallback). > > > I don't see any problem with the PEP as it stands (the "Application > Configuration" section). Middleware and apps can read the environ > variables they care about. As the PEP says: > > "But, most existing applications and frameworks will probably only need > a single configuration value from environ, to indicate the location of > their application or framework-specific configuration file(s)." I'm not proposing this effect the WSGI PEP at all, or hold it up at all. (BTW, Phillip: is there anything keeping it from going final just like it is?) >>This way at least the user has a chance of keeping their >>configuration files under control. If they are already >>scattered about, then they can probably stay that way. > > > So you want them all in the same folder or file? I can't figure out > exactly what concrete behavior you're trying to promote (or avoid). I'm > getting lost in the rabbit holes. It seems to me there are at least five > separate issues here: > > 1. How a given server populates wsgi environ dicts. > 2. Dynamic imports from dotted package names. A minor issue, but > recurring. This is quite separate. > 3. How to pass config data through a WSGI chain. In my mind, that's > already specified: environ. Either we put them as a normal environmental variable (e.g., environ['APP_INSTANCE_HOME']), or the are more structured and go in some other variable. I'd like the more structured approach, as the configuration can only be extremely minimal otherwise (i.e., point to configuration files). > 4. How to load and normalize complex config data from various sources: > ini, xml, yaml, zconfig (heh, just noticed the "XYZ" acrostic ;). That's a separate concern I'm not too worried about. > 5. How to minimize config file "spread" (?) This is what I'm thinking about (and it relates some to 1). If I have an application that uses several separate components, I want the application to have a single configuration file. And it's always nice if you can give some of those values on the command line, which is where the server may come in. Of course, I could probably fake it given a frontend script written specifically with those components in mind. That would call for zero configuration on the part of the components -- rather everything is specified explicitly during construction (i.e., keyword arguments). And maybe that's okay...? -- Ian Bicking / ianb@colorstudy.com / http://blog.ianbicking.org From ianb at colorstudy.com Sun Nov 14 14:46:23 2004 From: ianb at colorstudy.com (Ian Bicking) Date: Sun Nov 14 09:46:10 2004 Subject: [Web-SIG] Re: WSGI and Configuration In-Reply-To: <5.1.1.6.0.20041113124543.0322de80@mail.telecommunity.com> References: <6654eac404111306515e443879@mail.gmail.com> <6654eac404111306515e443879@mail.gmail.com> <5.1.1.6.0.20041113124543.0322de80@mail.telecommunity.com> Message-ID: <419761AF.9060300@colorstudy.com> Phillip J. Eby: > *Shudder*. Ideally, a server would allow customizing sys.path at least > long enough to import/setup the application. Otherwise, we lose out on > being able to e.g. deploy an application in a zipfile. (Wouldn't that be > nice?) Eh. Unpacking files isn't that hard, is it? A lot easier than figuring out sys.path, dealing with ambiguous names or name conflicts between separate applications or components, etc. I hate sys.path. And the two aren't mutually exclusive. I should look at py.path (http://codespeak.net/py), as it has code along these lines (py.path.local.local.LocalPath.getpycodeobj and py.path.common.FSPathBase.getpymodule). Importing from arbitrary locations is also necessary if Python web programming is able to feel like some other kinds of web programming; e.g., PHP/ASP. While I wouldn't advocate that for every application or environment, I think it's a valid use case. > I don't think PEAK's import tools really have much to offer here, unless > you just mean the convenient 'importString()' function. Couple that with > maybe some temporary additions to sys.path, and you're set. I don't really think it'll work if they are temporary. Because sys.path effects all imports (and worse, implicitly and inconsistently), messing with it and then undoing that will cause confusion. I'd rather mangle things from the beginning (e.g., name a module 'frompath.path_to_module'), at least that is predictable. > Of course, of the Python web servers out there, I'm thinking only > mod_python and modjy are really going to be able to handle this > well. mod_python can run apps in separate interpreters, and each can have > its own, completely transparent sys.path. modjy uses Jython, so in > principle it could run apps in different interpreters, though I don't think > it currently does. I don't think anything but CGI can handle this. Since there's persistent effects when you change sys.path (like modules left around that are named according to the sys.path that was in effect when they were imported), you could mess things up for later requests. And it will be incredibly confusing when it happens. > I *do* have a project on the back burner to make the CPython > multi-interpreter API accessible from Python code, though. Indeed, I > intend to write a PEP to propose standardizing a multi-interpreter API > for CPython, Jython, IronPython, and indeed all Python > implementations. But first, I'd like to finalize PEP 333. :) I always wondered why the multiple interpreters weren't accessible from Python code. But I can imagine that would open up a big can of worms... -- Ian Bicking / ianb@colorstudy.com / http://blog.ianbicking.org From ianb at colorstudy.com Sun Nov 14 15:02:59 2004 From: ianb at colorstudy.com (Ian Bicking) Date: Sun Nov 14 10:02:46 2004 Subject: [Web-SIG] Re: WSGI and Configuration In-Reply-To: <5.1.1.6.0.20041113131554.026a5cc0@mail.telecommunity.com> References: <5.1.1.6.0.20041113131554.026a5cc0@mail.telecommunity.com> Message-ID: <41976593.4070806@colorstudy.com> In this, I actually forget the use case that started me on this. I want the configuration to be modifiable on a per-URL basis. Specifically, wsgikit.urlparser will look for a configuration file in each directory it visits ("web.ini" or something); each configuration file it finds will be nested, taking precendence but not entirely hiding previous configuration files. In the simplest case, an application would simply be configured with a single .ini file in the root of the application. Of course, there are problems with this. Like, the server lives above urlparser, so it won't see what urlparser does, and it can't take configuration values from web.ini. So really what I'm thinking about is something like .htaccess in Apache. There's a bunch of values that urlparser will take, like extensions to display or hide, adding new handlers for extensions, maybe mime types, ways of folding two directories together, etc. But I also want any application or middleware below urlparser to also be configurable. E.g., setting up a different email address for errors based on the path. One possibility I've used before is just putting all this stuff in __init__.py, and maybe having urlparser look for a specially-named variable there. This is good for some things. But that can be confusing when there's both a Python data structure and a config file, since I don't want to use Python modules everywhere. -- Ian Bicking / ianb@colorstudy.com / http://blog.ianbicking.org From py-web-sig at xhaus.com Sun Nov 14 17:21:16 2004 From: py-web-sig at xhaus.com (Alan Kennedy) Date: Sun Nov 14 17:19:23 2004 Subject: [Web-SIG] Re: WSGI and Configuration In-Reply-To: <5.1.1.6.0.20041113124543.0322de80@mail.telecommunity.com> References: <6654eac404111306515e443879@mail.gmail.com> <6654eac404111306515e443879@mail.gmail.com> <5.1.1.6.0.20041113124543.0322de80@mail.telecommunity.com> Message-ID: <419785FC.5010409@xhaus.com> [Peter Hunt] >>> Why don't we just let each middleware/gateway/application handle >>> configuration by itself? Sure, it's a pain, but it's the defacto way >>> to do it. [Alan Kennedy] >> I disagree. >> >> If we permit "the market" to decide its preferred form of >> configuration, we're going to end up with a babel of configuration >> file formats. [Phillip J. Eby] > This babel you speak of, already exists. It's not WSGI's job to force > applications -- or servers -- into a single configuration format. > > OTOH, I do believe that *deployment* configuration (i.e. telling apps or > middleware where to *find* their configuration) is an appropriate > responsibility of a WSGI server, and that having a standard way to get > that information from the server to the app is an appropriate goal for > the spec. [Alan Kennedy] >> For example, say that the convention is to configure middleware >> through server/gateway configuration files. Authors of WSGI middleware >> would then have to document how to configure their component in >> several different configuration languages, each of which have subtly >> different quoting, escaping, encoding, etc, issues, for example: >> Apache httpd.conf markup language vs. XML (j2ee, etc) [Phillip J. Eby] > I think you're making this more complicated than it is. Do Java > application authors have to document every web server's configuration, > or do they say, "here's the servlets, these are their options, see your > server's doc for how to deploy them"? Well, java authors don't have to document every web servers config because J2EE has XML standards for all aspects of deployment configuration. http://java.sun.com/dtd/ Note that this standardization facilitates the development of end-user tools (e.g. with easy-to-use GUIs, or autogeneration with XSLT stylesheets, etc) for simplified J2EE deployment. [Alan Kennedy] >> IMHO, we should state some simple requirements for how we would like >> configuration to be handled. Here is an idea of the type of thing I mean >> >> 1. In order to reduce the documentation workload on middleware and >> framework authors, it is desirable to have a single configuration >> language which is supported in all WSGI environments. >> >> 2. In order to simplify the task of WSGI server administrators, it is >> desirable that the configuration of an entire middleware stack be >> storable in a single file/hierarchy of nested/include files. >> >> 3. In order to maximise internationalization opportunities, the chosen >> configuration mechanism should support the widest possible range of >> character encodings, and it should be easy for the user to explicitly >> specify the encoding. >> >> On the latter point, I believe we need to discourage ascii-centrism >> and encourage unicode-awareness. More international dialogue! ;-) I forgot to add what I consider to be another important requirement: 4. Ideally, it should be possible to generate deployment configuration files automatically, e.g. from GUI programs, specialized web-apps, etc. This is to support development of tools which simplify deployment configuration, thus facilitating ease-of-deployment for non-technical users. I think that in order to progress this discussion, we need to have a clearer definition of middleware, how middleware components are used, and why. My understanding of middleware is as follows. Among other things, middleware components should enable implementation of functionality that is common to all web applications. This is to facilitate standardization and reuse of such components across WSGI environments, and to enable WSGI users to select "best-of-breed" components for particular functions. Examples include 1. Authentication. Authentication is a very common function for web applications, and implementations of authentication functionality can range from simple (e.g. textual list of name/password/role triples) to complex (e.g. auth data stored in an LDAP server). 2. Session-handling. Session-handling is a complex area, requiring handling of cookies, url-rewriting, persistence (RDBMS, flat-file, etc), security (e.g. secure IDs, etc) and potentially syndication of sessions across a federation of cooperating servers. This is one area where almost every single python web application/framework has re-invented the wheel, but in a different shape every time, thus preventing reuse. In an ideal world, I would like it to be possible to use WSGI middleware to create or extend compound applications. A good example of this is TRAC (http://www.edgewall.com/trac/), which integrates the following facilities in a single integrated whole 1. Source code repository browser 2. Ticket tracking system (i.e. bugs, etc) 3. Wiki 4. Timeline management But TRAC is essentially a set of separate components, each implemented as a separate CGI script, which provide views of and access to the contents of several underlying databases. If it were possible to separate out the TRAC authentication and session-handling into WSGI middleware components, then it could be possible to seamlessly extend TRAC to support other features, e.g. Blogs, CVS-repository browsing (TRAC is currently svn only), etc. For example, if the auth were separated out, then I could use the same auth middleware/database to support a blogging system, which could be "integrated" into TRAC by mapping a new URL hierarchy into the TRAC URL-space. Picture a situation where a deployer is trying to build a middleware stack that implements an "application", which is really the invocatrion of a series of middleware components. If the deployer has to work in different configuration file formats for each middleware component, then they will have to learn several different configuration syntaxes. Also, they would mostly have to edit the configuration files manually: It would also be much more difficult to write standardized configuration management tools which would allow configuration of the stack/application through a GUI or a web front-end. Sure, there is an argument to be made that these are all framework concerns, i.e. that gluing application components together is a framework-specific concern. But the argument could also be made that these are server concerns, and that standardised middleware configuration could be used to facilitate gluing together disparate middleware components and applications to make a seamless whole, without the involvement of a framework. So I suppose what I am really saying is 1. I think there is an opportunity here, by standardizing middleware configuration, to forge a standard for total portability of middleware between WSGI environments. 2. That such a standard would also be used as standard configuration for frameworks. 3. That a combination of multiple connected middleware components *is* an application. 4. That a standardized method of configuring, connecting and invoking middleware components *is* a framework. One issue I think hasn't been addressed is how to instruct a middleware component what is the next application/middleware to be invoked in the stack. If I build a middleware stack, with say auth and session components at the bottom, and a variety of applications on top (which vary by URL), how do I instruct the auth component to invoke the session component next? Through an entry in the WSGI environ dict? Somehow, I get the feeling that my picture of middleware components doesn't gel with other people's views :-) Regards, Alan. From pje at telecommunity.com Sun Nov 14 17:56:02 2004 From: pje at telecommunity.com (Phillip J. Eby) Date: Sun Nov 14 17:55:34 2004 Subject: [Web-SIG] WSGI and Configuration In-Reply-To: <3A81C87DC164034AA4E2DDFE11D258E32451F3@exchange.hqamor.amo rhq.net> Message-ID: <5.1.1.6.0.20041114113916.020e2020@mail.telecommunity.com> At 11:53 PM 11/13/04 -0800, Robert Brewer wrote: > Phillip's idea about passing >configs in a separate call seems like overkill to me--applications which >are bare functions (not classes) will have to grow a wrapper to receive >the configs, at the least. My current proposal doesn't require this; instead, servers are asked to support importing *either* an application object or a setup object. My main motivation for recommending that servers provide support for "setup objects" is that some existing apps/frameworks aren't really suited to a configuration-on-demand setup, and it's harder to write code to handle it. So, applications that need setup can choose to be deployed that way, while still allowing users a "scriptless" deployment. In any case, I consider "Scriptless Deployment" to be an optional WSGI extension anyway. But, whatever we end up recommending, there will be support routines in wsgiref to make the server implementer's job easier. One thought that occurs to me is that we *could* create a ConfigParser-based format to be a "deployment configuration" for an application. It might contain a WSGI section that describes how to load and start the application, and any requirements such as threadability. It could also contain server-specific configuration, such that an application developer could include recommended settings for different servers. And the remaining sections would be for the application's use. A reference to the loaded configuration object could be included in a 'wsgi.config' environment variable. That's rather a lot to specify, but it would reduce the server-specific configuration format to be just mapping a URI location to a WSGI deployment file. The rest could then be managed in the deployment file. From pje at telecommunity.com Sun Nov 14 17:59:52 2004 From: pje at telecommunity.com (Phillip J. Eby) Date: Sun Nov 14 17:59:22 2004 Subject: [Web-SIG] WSGI and Configuration In-Reply-To: <41975A3A.9040203@colorstudy.com> References: <3A81C87DC164034AA4E2DDFE11D258E32451F3@exchange.hqamor.amorhq.net> <3A81C87DC164034AA4E2DDFE11D258E32451F3@exchange.hqamor.amorhq.net> Message-ID: <5.1.1.6.0.20041114115614.02d3aa80@mail.telecommunity.com> At 07:14 AM 11/14/04 -0600, Ian Bicking wrote: >Robert Brewer wrote: >>I don't see any problem with the PEP as it stands (the "Application >>Configuration" section). Middleware and apps can read the environ >>variables they care about. As the PEP says: >>"But, most existing applications and frameworks will probably only need >>a single configuration value from environ, to indicate the location of >>their application or framework-specific configuration file(s)." > >I'm not proposing this effect the WSGI PEP at all, or hold it up at >all. (BTW, Phillip: is there anything keeping it from going final just >like it is?) I still want to replace the current "Threading" section with an overview of threading models and sync vs. async issues. Also, based on my observations to date of the various WSGI server and app implementations out there, I think we really do need a convention that allows "scriptless deployment", even if it's considered an optional extension. From pje at telecommunity.com Sun Nov 14 18:15:45 2004 From: pje at telecommunity.com (Phillip J. Eby) Date: Sun Nov 14 18:15:16 2004 Subject: [Web-SIG] Re: WSGI and Configuration In-Reply-To: <419761AF.9060300@colorstudy.com> References: <5.1.1.6.0.20041113124543.0322de80@mail.telecommunity.com> <6654eac404111306515e443879@mail.gmail.com> <6654eac404111306515e443879@mail.gmail.com> <5.1.1.6.0.20041113124543.0322de80@mail.telecommunity.com> Message-ID: <5.1.1.6.0.20041114120532.02d3eec0@mail.telecommunity.com> At 07:46 AM 11/14/04 -0600, Ian Bicking wrote: >I always wondered why the multiple interpreters weren't accessible from >Python code. But I can imagine that would open up a big can of worms... Multiple interpreters are actually pretty simple, at least in principle. AFAIK, the main issues they have are with sharing extension modules across interpreters. One particularly useful fact about multiple interpreters, however, is that they have separate sys modules, and therefore separate sys.modules and sys.path. This makes them ideal for separating web applications (and their dependencies) from one another, which is no doubt why mod_python uses them. Anyway, it isn't necessary to change sys.path to execfile a startup script. It probably makes more sense to simply allow specifying any additions to sys.path that an application needs, leaving it up to the user to address version conflicts and the like. (Though the server could warn that there were same-named modules or packages supplied by different applications' sys.path additions.) IMO, the long term solution is the multi-interpreter API, though. While Java programmers complain of "classpath hell", in Python we should be so lucky as to be able to have the code loaded multiple times. From pje at telecommunity.com Sun Nov 14 18:20:47 2004 From: pje at telecommunity.com (Phillip J. Eby) Date: Sun Nov 14 18:20:19 2004 Subject: [Web-SIG] Re: WSGI and Configuration In-Reply-To: <419785FC.5010409@xhaus.com> References: <5.1.1.6.0.20041113124543.0322de80@mail.telecommunity.com> <6654eac404111306515e443879@mail.gmail.com> <6654eac404111306515e443879@mail.gmail.com> <5.1.1.6.0.20041113124543.0322de80@mail.telecommunity.com> Message-ID: <5.1.1.6.0.20041114121755.02d40090@mail.telecommunity.com> At 04:21 PM 11/14/04 +0000, Alan Kennedy wrote: >1. I think there is an opportunity here, by standardizing middleware >configuration, to forge a standard for total portability of middleware >between WSGI environments. If we can first establish a basis for configuring basic application deployment, I think we'll be in a better position to tackle that idea, just as we're now able to consider configuration and deployment, because we first settled the communication spec. IOW, I'd want to see if we can come up with a nice clean deployment spec, and then see how it could be extended to support middleware, rather than dilute the initial focus. From ianb at colorstudy.com Mon Nov 15 02:31:04 2004 From: ianb at colorstudy.com (Ian Bicking) Date: Sun Nov 14 21:30:51 2004 Subject: [Web-SIG] Re: WSGI and Configuration In-Reply-To: <419785FC.5010409@xhaus.com> References: <6654eac404111306515e443879@mail.gmail.com> <6654eac404111306515e443879@mail.gmail.com> <5.1.1.6.0.20041113124543.0322de80@mail.telecommunity.com> <419785FC.5010409@xhaus.com> Message-ID: <419806D8.1050607@colorstudy.com> Alan Kennedy wrote: > My understanding of middleware is as follows. > > Among other things, middleware components should enable implementation > of functionality that is common to all web applications. This is to > facilitate standardization and reuse of such components across WSGI > environments, and to enable WSGI users to select "best-of-breed" > components for particular functions. This is definitely what I'm getting at as well. To do this we'd have to agree on WSGI keys and semantics for those keys. E.g., session middleware might have a key "session.api", which was an object that had methods for things like .sid, .expire(), .clear(), etc. Or maybe that would be presented in several keys; I think if the API has multiple levels of compliance, multiple keys would be a good way to indicate that. Anyway, that process of standardization has to happen for each piece of middleware independently. The other part which relates to configuration is how to keep this under control for the person who is deploying an application using this middleware. Right now the functionality of these pieces of middleware are provided as part of larger frameworks. It means you can't pick and choose, but in reality no one wants to pick and choose -- they'd much rather be presented with a single good choice. As implementors this choice seems good, but we need to insulate users from it. One way is to package a bunch of the middleware into one hunk. This is pretty easy: def framework(application): return middleware1( middleware2(middleware3(middleware4(application)))) Of course, that only works if the middleware is self-configuring, which is why I'm thinking about that. But Phillip is thinking about how we configure this stack. I guess if we start with configuring the stack it'll be clearer how to reference the pieces, and what information they'll have available to them. Well, I think the referencing is more interesting than the information available, because I'd rather leave the configuration until runtime. And maybe referencing isn't hard. Each piece implicitly has a unique name associated with it that it uses for its keys in the environ dict. Well, there's nothing ensuring it's unique. And there's no way to deal with conflicts now. Or middleware that shows up multiple times (which is plausible). Well, maybe it's not easy, but it's the same problem we already have. [lots of stuff I agree with snipped...] > One issue I think hasn't been addressed is how to instruct a middleware > component what is the next application/middleware to be invoked in the > stack. If I build a middleware stack, with say auth and session > components at the bottom, and a variety of applications on top (which > vary by URL), how do I instruct the auth component to invoke the session > component next? Through an entry in the WSGI environ dict? I think the composition generally happens when the application is started up, as opposed to when a request is processed. Well, that's only partly true. URL resolution is a common case where the next piece of the stack is found dynamically. And any dynamic application is another opportunity for dynamic middleware. For instance, if my application needs session handling and no session handler has been put into the stack yet, maybe I'll put one in on my own. -- Ian Bicking / ianb@colorstudy.com / http://blog.ianbicking.org From py-web-sig at xhaus.com Mon Nov 15 01:13:49 2004 From: py-web-sig at xhaus.com (Alan Kennedy) Date: Mon Nov 15 01:12:10 2004 Subject: [Web-SIG] Re: WSGI and Configuration In-Reply-To: <419806D8.1050607@colorstudy.com> References: <6654eac404111306515e443879@mail.gmail.com> <6654eac404111306515e443879@mail.gmail.com> <5.1.1.6.0.20041113124543.0322de80@mail.telecommunity.com> <419785FC.5010409@xhaus.com> <419806D8.1050607@colorstudy.com> Message-ID: <4197F4BD.2010007@xhaus.com> [Alan Kennedy] >> One issue I think hasn't been addressed is how to instruct a >> middleware component what is the next application/middleware to be >> invoked in the stack. If I build a middleware stack, with say auth >> and session components at the bottom, and a variety of applications >> on top (which vary by URL), how do I instruct the auth component to >> invoke the session component next? Through an entry in the WSGI >> environ dict? [Ian Bicking] > I think the composition generally happens when the application is > started up, as opposed to when a request is processed. > > Well, that's only partly true. URL resolution is a common case where > the next piece of the stack is found dynamically. And any dynamic > application is another opportunity for dynamic middleware. For > instance, if my application needs session handling and no session > handler has been put into the stack yet, maybe I'll put one in on my > own. So ISTM that discussing configuration of middleware stacks is partly a discussion about an URI->object resolution mechanism, i.e. mapping an URI hierarchy to a tree of python objects. The shape of the python object tree may be either 1. Static, i.e. built at container start-time, and where the container selects target application objects based on URI components in each request. 2. Dynamic, where the application objects themselves get to decide where the request is routed next, quixote-style. But it is still the container's job to actually resolve/import the next object down in the tree. So I think we're definitely in framework-land. I'm beginning to think that maybe the concept of framework-agnosticism doesn't fit with the concept of middleware stacks. A mechanism for constructing middleware stacks is a framework, an instance of a middleware stack is an application/hierarchy-of-nested-applications. Maybe it's time to start thinking about WSGI Layer 2:- The middleware layer? Or maybe we need to find other middleware examples besides authentication and session handling, which are the two things most often "pre-decided" with many servers and almost any web programming framework in any language (because they're such a pain). Maybe they are special cases that need to be considered separately anyway? Regards, Alan. From ianb at colorstudy.com Mon Nov 15 06:40:02 2004 From: ianb at colorstudy.com (Ian Bicking) Date: Mon Nov 15 01:39:49 2004 Subject: [Web-SIG] Re: WSGI and Configuration In-Reply-To: <4197F4BD.2010007@xhaus.com> References: <6654eac404111306515e443879@mail.gmail.com> <6654eac404111306515e443879@mail.gmail.com> <5.1.1.6.0.20041113124543.0322de80@mail.telecommunity.com> <419785FC.5010409@xhaus.com> <419806D8.1050607@colorstudy.com> <4197F4BD.2010007@xhaus.com> Message-ID: <41984132.8060906@colorstudy.com> Alan Kennedy wrote: > So ISTM that discussing configuration of middleware stacks is partly a > discussion about an URI->object resolution mechanism, i.e. mapping an > URI hierarchy to a tree of python objects. The shape of the python > object tree may be either > > 1. Static, i.e. built at container start-time, and where the container > selects target application objects based on URI components in each request. Well, this doesn't preclude dynamic either. Unless the server requires that PATH_INFO be empty, the application always has the option to delegate further. All WSGI applications should look the same to the server/gateway, regardless of if they are middleware of terminal applications. > 2. Dynamic, where the application objects themselves get to decide where > the request is routed next, quixote-style. But it is still the > container's job to actually resolve/import the next object down in the > tree. > > So I think we're definitely in framework-land. > > I'm beginning to think that maybe the concept of framework-agnosticism > doesn't fit with the concept of middleware stacks. A mechanism for > constructing middleware stacks is a framework, an instance of a > middleware stack is an application/hierarchy-of-nested-applications. > > Maybe it's time to start thinking about WSGI Layer 2:- The middleware > layer? You mean standardizing middleware, or extending WSGI? I'm comfortable with what WSGI allows, I don't think it needs to be extended at all. As for standardizing middleware, I think that's a separate standard by a separate name, and we'll need some implementation experience under our belts. > Or maybe we need to find other middleware examples besides > authentication and session handling, which are the two things most often > "pre-decided" with many servers and almost any web programming framework > in any language (because they're such a pain). Maybe they are special > cases that need to be considered separately anyway? Well, here's the middleware I'm using: * cgitb_catcher, catches unhandled exceptions and formats a response using cgitb. * dispatch, a crappy URL parser; only interesting in that it also can add middleware via the URL (useful for testing) * gzipper, a gzip-encoding middleware * httpexceptions, which catches specific exceptions (e.g., HTTPTemporaryRedirect) and turns them into proper responses. Probably the least WSGI-ish of these middlewares. * lint, a standard-verifying middleware that doesn't otherwise effect valid requests or responses * recursive, a middleware that allows for recursive calls into the application. It's limited to calls below its position in the middleware stack. This was necessary for implementing some Webware APIs. And it seems pretty useful too. It allows for forwarding (passing control) and inclusion (doing a recursive call). * session, a session handler * urlparser, a URL parsing middleware. It parses the first part of PATH_INFO, and finds the next resource. If the next resource is a directory, it creates a new URLParser and passes control to it; it also has hooks for adding other file->application converters. * webkit.wsgiwebkit.webkit, which just takes a whole bunch of these and puts them together. The only thing that has been very confusing for me is handling exceptions, and most of these don't do so very well. I think sessions would be easy to standardize, because they are pretty boring. You store stuff, later on you get it back. There's lots of possible features (e.g., storing in a database), but the API is pretty stable and understood irregardless of those features. Authentication is a little harder, but I think it's not too bad if you don't take on too much at once. I think it's only so complicated because authorization often gets folded into authentication. Authentication sources (e.g., LDAP) should be kept out of the middleware; instead a simple and neutral API for authentication sources should be used. -- Ian Bicking / ianb@colorstudy.com / http://blog.ianbicking.org From floydophone at gmail.com Tue Nov 16 05:15:45 2004 From: floydophone at gmail.com (Peter Hunt) Date: Tue Nov 16 05:15:56 2004 Subject: [Web-SIG] Ruby on Rails for Python Message-ID: <6654eac404111520158f076c5@mail.gmail.com> I'm putting together a competition framework for Python which is similar to Ruby on Rails. I'm going to reuse as much of other work as I can, so I am not saturating the market with YAPWF. I'm going to use Cheetah and SQLObject, and it's going to generate a WSGI application. My question: is there a good stack of WSGI middleware for sessions and other stuff like that? From ianb at colorstudy.com Wed Nov 17 18:15:52 2004 From: ianb at colorstudy.com (Ian Bicking) Date: Wed Nov 17 18:18:52 2004 Subject: [Web-SIG] Ruby on Rails for Python In-Reply-To: <6654eac404111520158f076c5@mail.gmail.com> References: <6654eac404111520158f076c5@mail.gmail.com> Message-ID: <419B8748.10605@colorstudy.com> Peter Hunt wrote: > I'm putting together a competition framework for Python which is > similar to Ruby on Rails. I'm going to reuse as much of other work as > I can, so I am not saturating the market with YAPWF. I'm going to use > Cheetah and SQLObject, and it's going to generate a WSGI application. > My question: is there a good stack of WSGI middleware for sessions and > other stuff like that? Well, WSGIKit has a session middleware, among the other middleware I noted before. It's not that great, but it should at least serve as a placeholder so you can work on more interesting aspects. If you have other ideas for middleware, please bring them up here, and maybe we can collaborate. I don't really know much about the internal architecture of Rails, so I can't say much more. I think it has object publishing of a sort; wsgikit.urlparser may still be useful, if the publishing starts with disk files, then digs deeper into the objects (urlparser doesn't dig into objects, but it generally hands off control at the first opportunity it gets, so the object itself can handle the rest of the URL). There could be a number of interesting enhancements here as well, some of which might fit into this project, some which might not. Facilitating URL introspection would be quite useful. Most of it will probably be libraries more than middleware. Which is probably better, easier to test, understand, and reuse. Some of my middleware should be stripped down so it's just a smaller wrapper around more generic libraries. For form generation, you might want to look at my validation project at svn://colorstudy.com/trunk/Validator -- I haven't settled on on the module names, but the basic interface is fairly mature. I'm also interested in ways of flattening the whole process by embedding the validation requirements in the form's HTML. -- Ian Bicking / ianb@colorstudy.com / http://blog.ianbicking.org From terrel at terrelshumway.com Fri Nov 19 05:07:55 2004 From: terrel at terrelshumway.com (Terrel Shumway) Date: Fri Nov 19 05:08:03 2004 Subject: [Web-SIG] middleware example Message-ID: <419D719B.4030603@terrelshumway.com> > > >Or maybe we need to find other middleware examples besides >authentication and session handling, which are the two things most often >"pre-decided" with many servers and almost any web programming framework >in any language (because they're such a pain). Maybe they are special >cases that need to be considered separately anyway? > This is a special case of authentication and sessions: I have an app that runs in http://myserver.dom/ I have a shopping cart that needs to collect payment information through a secure connection https://secure.server.dom/cgi-bin/order I want the payment page to match the look and feel of the unsecured site, so I make the templates available on the secure site. Now: How do I choose which set of templates to use? 1. The merchant passes a cookie to the secure site 2. The middleware decodes the cookie and adds the appropriate merchant-specific directory to the template search path e.g. env["cheetah.templatepath"].insert(0,merchantdir) 3. The application code is totally agnostic to the use of a different set of templates -- all it knows is that a new variable "whizcart.merchant" is added to the environment, and it doesn't care how it got there. From ianb at colorstudy.com Fri Nov 19 05:50:58 2004 From: ianb at colorstudy.com (Ian Bicking) Date: Fri Nov 19 05:51:00 2004 Subject: [Web-SIG] middleware example In-Reply-To: <419D719B.4030603@terrelshumway.com> References: <419D719B.4030603@terrelshumway.com> Message-ID: <419D7BB2.8020100@colorstudy.com> Terrel Shumway wrote: >> Or maybe we need to find other middleware examples besides >> authentication and session handling, which are the two things most >> often "pre-decided" with many servers and almost any web programming >> framework in any language (because they're such a pain). Maybe they >> are special cases that need to be considered separately anyway? >> > > This is a special case of authentication and sessions: > > I have an app that runs in http://myserver.dom/ > I have a shopping cart that needs to collect > payment information through a secure connection > https://secure.server.dom/cgi-bin/order > > I want the payment page to match the look and feel > of the unsecured site, so I make the templates > available on the secure site. Now: How do I choose > which set of templates to use? > > 1. The merchant passes a cookie to the secure site > 2. The middleware decodes the cookie and adds the > appropriate merchant-specific directory to the > template search path > e.g. env["cheetah.templatepath"].insert(0,merchantdir) This is definitely a good example of a place where it will help if the configuration is stored in the WSGI environment. If you used static configuration, you wouldn't be able to modify this on a per-request basis. Of course, you could put the dynamicism in elsewhere, but I think it will be better allowed for if it's part of the request. -- Ian Bicking / ianb@colorstudy.com / http://blog.ianbicking.org From floydophone at gmail.com Sat Nov 20 05:57:18 2004 From: floydophone at gmail.com (Peter Hunt) Date: Sat Nov 20 05:57:19 2004 Subject: [Web-SIG] Rails competitor Message-ID: <6654eac404111920572b5d7a73@mail.gmail.com> http://st0rm.hopto.org/subway.zip Anyone want to work on this? From floydophone at gmail.com Thu Nov 25 18:38:28 2004 From: floydophone at gmail.com (Peter Hunt) Date: Thu Nov 25 18:38:32 2004 Subject: [Web-SIG] WSGI adoption Message-ID: <6654eac404112509385ce97e44@mail.gmail.com> It's going slowly but surely, as I can tell from my Googling. I think we could speed adoption very quickly if we all got together and created stable, tested, proven, and officialy WSGI gateways. I think the following list would be a good place to start, with the important ones first and the less-important ones near the bottom: - CGI - FastCGI - mod_python - Microsoft ASP+Python - Twisted - Zope (2 or 3) What do you guys think? If we go to all the framework writers and say "if you adopt WSGI your framework will automatically run on all of these platforms", don't you think it's a no-brainer to support it? Just my 2 cents. From david at sundayta.com Thu Nov 25 19:01:34 2004 From: david at sundayta.com (David Warnock) Date: Thu Nov 25 19:01:43 2004 Subject: [Web-SIG] WSGI adoption In-Reply-To: <6654eac404112509385ce97e44@mail.gmail.com> References: <6654eac404112509385ce97e44@mail.gmail.com> Message-ID: <41A61DFE.1080500@sundayta.com> Peter, > It's going slowly but surely, as I can tell from my Googling. I think > we could speed adoption very quickly if we all got together and > created stable, tested, proven, and officialy WSGI gateways. > > I think the following list would be a good place to start, with the > important ones first and the less-important ones near the bottom: > > - CGI > - FastCGI > - mod_python > - Microsoft ASP+Python > - Twisted > - Zope (2 or 3) I would add quixotes SCGI, it seems to be good and stable. > What do you guys think? If we go to all the framework writers and say > "if you adopt WSGI your framework will automatically run on all of > these platforms", don't you think it's a no-brainer to support it? Absoloutely, I have been discussing this on the Quixote list and if wsgi seems to be a better way to support multiple servers then they will go for it. Dave -- David Warnock: Sundayta Ltd. http://www.sundayta.com From pje at telecommunity.com Thu Nov 25 19:05:23 2004 From: pje at telecommunity.com (Phillip J. Eby) Date: Thu Nov 25 19:04:13 2004 Subject: [Web-SIG] WSGI adoption In-Reply-To: <6654eac404112509385ce97e44@mail.gmail.com> Message-ID: <5.1.1.6.0.20041125125555.02756410@mail.telecommunity.com> At 12:38 PM 11/25/04 -0500, Peter Hunt wrote: >It's going slowly but surely, as I can tell from my Googling. I think >we could speed adoption very quickly if we all got together and >created stable, tested, proven, and officialy WSGI gateways. > >I think the following list would be a good place to start, with the >important ones first and the less-important ones near the bottom: > >- CGI >- FastCGI >- mod_python >- Microsoft ASP+Python >- Twisted >- Zope (2 or 3) > >What do you guys think? I do intend to add mod_python and Twisted gateways to 'wsgiref', in addition to the CGI gateway that's already in it. For FastCGI, the PEAK runners have been stable for some time, since I originally built them with an older, more CGI-like WSGI, over a year ago. That leaves ASP+Python and Zope. I don't have any experience with (or access to) the former, but I gather that the Zope Corp. folks are more interested in getting Zope to run under other servers (especially Twisted and Apache) than they are in getting other WSGI stuff to run under the Zope servers. I agree, at least from the perspective that until WSGI has enough application and framework support, there isn't going to be as much demand for running WSGI apps under Zope servers. >If we go to all the framework writers and say >"if you adopt WSGI your framework will automatically run on all of >these platforms", don't you think it's a no-brainer to support it? What I'd really like to do next is standardize on a deployment configuration format (preferably ConfigParser-based, as the format is simple, and support is in the stdlib). One big advantage of having such a format is that I could implement basic support for it in 'wsgiref', such that a given server just needs to call a function with a filename (or stream, perhaps) to load up a nicely-configured application object, all ready for use with the appropriate WSGI handler class. Thus, all the wsgiref-based servers would enjoy instant access to the deployment format. At that point, the documentation needed for an end user to deploy something is just how to tell a given web server where the deployment file is, and what URL it should be made available under. And, for the framework or application author, they just need to document what should go in the file. From remi at cherrypy.org Thu Nov 25 19:05:57 2004 From: remi at cherrypy.org (Remi Delon) Date: Thu Nov 25 19:06:00 2004 Subject: [Web-SIG] WSGI adoption In-Reply-To: <6654eac404112509385ce97e44@mail.gmail.com> References: <6654eac404112509385ce97e44@mail.gmail.com> Message-ID: <41A61F05.5090604@cherrypy.org> Peter Hunt wrote: > It's going slowly but surely, as I can tell from my Googling. I think > we could speed adoption very quickly if we all got together and > created stable, tested, proven, and officialy WSGI gateways. > > I think the following list would be a good place to start, with the > important ones first and the less-important ones near the bottom: > > - CGI > - FastCGI > - mod_python > - Microsoft ASP+Python > - Twisted > - Zope (2 or 3) Well, we've been pretty quiet on this list, but you can add CherryPy as well :-) There is a lot of development effort going on at the moment on CherryPy2, and WSGI is definitely on the list of features we want CherryPy to have. We even have an experimental WSGI implementation already. Remi. From smulloni at smullyan.org Thu Nov 25 19:42:58 2004 From: smulloni at smullyan.org (Jacob Smullyan) Date: Thu Nov 25 19:43:01 2004 Subject: [Web-SIG] WSGI adoption In-Reply-To: <41A61F05.5090604@cherrypy.org> References: <6654eac404112509385ce97e44@mail.gmail.com> <41A61F05.5090604@cherrypy.org> Message-ID: <20041125184258.GA4944@smullyan.org> On Thu, Nov 25, 2004 at 06:05:57PM +0000, Remi Delon wrote: > Peter Hunt wrote: > >I think the following list would be a good place to start, with the > >important ones first and the less-important ones near the bottom: > > > >- CGI > >- FastCGI > >- mod_python > >- Microsoft ASP+Python > >- Twisted > >- Zope (2 or 3) > > Well, we've been pretty quiet on this list, but you can add CherryPy as > well :-) SkunkWeb, too, is preparing to jump on the WSGI bandwagon! js -- Jacob Smullyan -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://mail.python.org/pipermail/web-sig/attachments/20041125/5a8fe603/attachment.pgp From py-web-sig at xhaus.com Thu Nov 25 19:50:03 2004 From: py-web-sig at xhaus.com (Alan Kennedy) Date: Thu Nov 25 19:51:16 2004 Subject: [Web-SIG] WSGI adoption In-Reply-To: <41A61DFE.1080500@sundayta.com> References: <6654eac404112509385ce97e44@mail.gmail.com> <41A61DFE.1080500@sundayta.com> Message-ID: <41A6295B.9060709@xhaus.com> [Peter Hunt] >> What do you guys think? If we go to all the framework writers and say >> "if you adopt WSGI your framework will automatically run on all of >> these platforms", don't you think it's a no-brainer to support it? [David Warnock] > Absoloutely, I have been discussing this on the Quixote list and if wsgi > seems to be a better way to support multiple servers then they will go > for it. I've got to say, I was disappointed when I read about the brand new Quixote 2.0 release, and saw that there was not a single mention of WSGI in the README or CHANGES files. I haven't looked at the Quixote 2.0 code at all. Perhaps there is code in there for WSGI, or someone has Quixote/WSGI code sitting on their hard-disk somewhere? Regards, Alan. From david at sundayta.com Thu Nov 25 21:51:02 2004 From: david at sundayta.com (David Warnock) Date: Thu Nov 25 21:51:09 2004 Subject: [Web-SIG] WSGI adoption In-Reply-To: <41A6295B.9060709@xhaus.com> References: <6654eac404112509385ce97e44@mail.gmail.com> <41A61DFE.1080500@sundayta.com> <41A6295B.9060709@xhaus.com> Message-ID: <41A645B6.3020103@sundayta.com> Alan, > I've got to say, I was disappointed when I read about the brand new > Quixote 2.0 release, and saw that there was not a single mention of WSGI > in the README or CHANGES files. Agreed. > I haven't looked at the Quixote 2.0 code at all. Perhaps there is code > in there for WSGI, or someone has Quixote/WSGI code sitting on their > hard-disk somewhere? Nope. But I did get this on the mailing list from Neil Schemenaur : > I wrote: > >>> [WSGI support] not my goal. One of my goals is to have Quixote >>> work with as many HTTP servers as possible and to make it easy to >>> switch between them. > > > Upon that response is probably more cryptic than necessary. What I > mean is that WSGI support itself means nothing to me. If supporting > WSGI allows me to achieve my real goal then it will be supported. > > Neil Dave -- David Warnock: Sundayta Ltd. http://www.sundayta.com From floydophone at gmail.com Thu Nov 25 22:57:30 2004 From: floydophone at gmail.com (Peter Hunt) Date: Thu Nov 25 22:57:32 2004 Subject: [Web-SIG] WSGI adoption In-Reply-To: <5.1.1.6.0.20041125125555.02756410@mail.telecommunity.com> References: <6654eac404112509385ce97e44@mail.gmail.com> <5.1.1.6.0.20041125125555.02756410@mail.telecommunity.com> Message-ID: <6654eac4041125135746e8e0a8@mail.gmail.com> Fair enough; we can drop Zope from the priority list. I'd suggest simply using plain Python as a configuration file format. It's just as easy to understand and far more flexible than ConfigParser. Also, in terms of configuration files, I think an instance of each middleware/application/gateway should get its own configuration file. While designing this configuration system, we should keep the idea of shared hosting in mind, and that the host may want to run certain pieces of middleware for everyone. On Thu, 25 Nov 2004 13:05:23 -0500, Phillip J. Eby wrote: > At 12:38 PM 11/25/04 -0500, Peter Hunt wrote: > > > >It's going slowly but surely, as I can tell from my Googling. I think > >we could speed adoption very quickly if we all got together and > >created stable, tested, proven, and officialy WSGI gateways. > > > >I think the following list would be a good place to start, with the > >important ones first and the less-important ones near the bottom: > > > >- CGI > >- FastCGI > >- mod_python > >- Microsoft ASP+Python > >- Twisted > >- Zope (2 or 3) > > > >What do you guys think? > > I do intend to add mod_python and Twisted gateways to 'wsgiref', in > addition to the CGI gateway that's already in it. For FastCGI, the PEAK > runners have been stable for some time, since I originally built them with > an older, more CGI-like WSGI, over a year ago. > > That leaves ASP+Python and Zope. I don't have any experience with (or > access to) the former, but I gather that the Zope Corp. folks are more > interested in getting Zope to run under other servers (especially Twisted > and Apache) than they are in getting other WSGI stuff to run under the Zope > servers. I agree, at least from the perspective that until WSGI has enough > application and framework support, there isn't going to be as much demand > for running WSGI apps under Zope servers. > > > >If we go to all the framework writers and say > >"if you adopt WSGI your framework will automatically run on all of > >these platforms", don't you think it's a no-brainer to support it? > > What I'd really like to do next is standardize on a deployment > configuration format (preferably ConfigParser-based, as the format is > simple, and support is in the stdlib). > > One big advantage of having such a format is that I could implement basic > support for it in 'wsgiref', such that a given server just needs to call a > function with a filename (or stream, perhaps) to load up a > nicely-configured application object, all ready for use with the > appropriate WSGI handler class. Thus, all the wsgiref-based servers would > enjoy instant access to the deployment format. > > At that point, the documentation needed for an end user to deploy something > is just how to tell a given web server where the deployment file is, and > what URL it should be made available under. And, for the framework or > application author, they just need to document what should go in the file. > > From carribeiro at gmail.com Thu Nov 25 23:23:08 2004 From: carribeiro at gmail.com (Carlos Ribeiro) Date: Thu Nov 25 23:23:40 2004 Subject: [Web-SIG] WSGI adoption In-Reply-To: <6654eac4041125135746e8e0a8@mail.gmail.com> References: <6654eac404112509385ce97e44@mail.gmail.com> <5.1.1.6.0.20041125125555.02756410@mail.telecommunity.com> <6654eac4041125135746e8e0a8@mail.gmail.com> Message-ID: <864d37090411251423122b92c@mail.gmail.com> On Thu, 25 Nov 2004 16:57:30 -0500, Peter Hunt wrote: > I'd suggest simply using plain Python as a configuration file format. > It's just as easy to understand and far more flexible than > ConfigParser. My $.02. If you need source code to configure a package, you aren't really configuring -- you're programming. Simple configuration file formats such as the INI-style used by ConfigParser restrict what can be done by configuration. This is good because avoids mistakes and abuses. If you need more flexibility, then it's better to do it in real code. Also, WSGI applications may end up being used by people who have little or no knowledge of Python. Keeping the config in a INI-style file facilitates things a lot, both for customization and also for support. That's all IMHO, really. Your mileage may vary. -- Carlos Ribeiro Consultoria em Projetos blog: http://rascunhosrotos.blogspot.com blog: http://pythonnotes.blogspot.com mail: carribeiro@gmail.com mail: carribeiro@yahoo.com From carribeiro at gmail.com Thu Nov 25 23:23:08 2004 From: carribeiro at gmail.com (Carlos Ribeiro) Date: Thu Nov 25 23:24:52 2004 Subject: [Web-SIG] WSGI adoption In-Reply-To: <6654eac4041125135746e8e0a8@mail.gmail.com> References: <6654eac404112509385ce97e44@mail.gmail.com> <5.1.1.6.0.20041125125555.02756410@mail.telecommunity.com> <6654eac4041125135746e8e0a8@mail.gmail.com> Message-ID: <864d37090411251423122b92c@mail.gmail.com> On Thu, 25 Nov 2004 16:57:30 -0500, Peter Hunt wrote: > I'd suggest simply using plain Python as a configuration file format. > It's just as easy to understand and far more flexible than > ConfigParser. My $.02. If you need source code to configure a package, you aren't really configuring -- you're programming. Simple configuration file formats such as the INI-style used by ConfigParser restrict what can be done by configuration. This is good because avoids mistakes and abuses. If you need more flexibility, then it's better to do it in real code. Also, WSGI applications may end up being used by people who have little or no knowledge of Python. Keeping the config in a INI-style file facilitates things a lot, both for customization and also for support. That's all IMHO, really. Your mileage may vary. -- Carlos Ribeiro Consultoria em Projetos blog: http://rascunhosrotos.blogspot.com blog: http://pythonnotes.blogspot.com mail: carribeiro@gmail.com mail: carribeiro@yahoo.com From pje at telecommunity.com Thu Nov 25 23:34:49 2004 From: pje at telecommunity.com (Phillip J. Eby) Date: Thu Nov 25 23:33:41 2004 Subject: [Web-SIG] WSGI adoption In-Reply-To: <6654eac4041125135746e8e0a8@mail.gmail.com> References: <5.1.1.6.0.20041125125555.02756410@mail.telecommunity.com> <6654eac404112509385ce97e44@mail.gmail.com> <5.1.1.6.0.20041125125555.02756410@mail.telecommunity.com> Message-ID: <5.1.1.6.0.20041125172640.0286c5f0@mail.telecommunity.com> At 04:57 PM 11/25/04 -0500, Peter Hunt wrote: >Fair enough; we can drop Zope from the priority list. > >I'd suggest simply using plain Python as a configuration file format. >It's just as easy to understand and far more flexible than >ConfigParser. Flexibility of specifying the content isn't really a plus here. End user editability, and *sectionability* are more important. That is, it should be easy to have sections for the app, the web server, and general WSGI information. For that matter, it should be possible for me to include settings for both mod_python and Twisted in the same configuration file, such that each one sees only the parts it cares about. That way, an application developer can minimize the tuning knowledge needed by an application deployer, for platforms the developer cares about. IMO, most of the content of the deployment configuration is either going to be constants or filenames. For filenames, ConfigParser lets you interpolate variables, so if you want brevity of expression you can still do that without going to the full generality of Python. >Also, in terms of configuration files, I think an instance of each >middleware/application/gateway should get its own configuration file. Yes, this is a per-instance deployment file I'm talking about. >While designing this configuration system, we should keep the idea of >shared hosting in mind, and that the host may want to run certain >pieces of middleware for everyone. I was thinking that part of the configuration passed to an application's setup would be an optional "next application" value. There are several ways that could be configured from the deployment file, such as simply specifying the filename of the deployment file for the next application, or by embedding a list of deployment files for middleware to be put "above" the current application. I don't have a firm proposal either way for the specific mechanism yet. From py-web-sig at xhaus.com Thu Nov 25 23:50:10 2004 From: py-web-sig at xhaus.com (Alan Kennedy) Date: Thu Nov 25 23:52:11 2004 Subject: [Web-SIG] WSGI adoption In-Reply-To: <6654eac404112509385ce97e44@mail.gmail.com> References: <6654eac404112509385ce97e44@mail.gmail.com> Message-ID: <41A661A2.5090506@xhaus.com> [Peter Hunt] > It's going slowly but surely, as I can tell from my Googling. Agreed: the google results for "download WSGI server" are disappointing, with one notable jythonic exception ;-) > I think > we could speed adoption very quickly if we all got together and > created stable, tested, proven, and officialy WSGI gateways. Definitely. I think we have a small perception problem, in that the existing WSGI servers and utilities are low visibility. They are all a part of another download, or reside in people's svn repositories, or are small utilities that don't have documentation, or even readily identifiable names ..... I think there are currently three pure python WSGI servers derived from SimpleHTTPServer. Perhaps someone could take it on themselves to go the last few steps and give one of them a name, write some simple WSGI-focussed docs, a setup.py and prepare a download package? > I think the following list would be a good place to start, with the > important ones first and the less-important ones near the bottom: > > - CGI Definitely the most important. And at least one already exists. All it requires is a little packaging. > - FastCGI I think this is more of minority architecture myself. > - mod_python This is the mainstream. Until WSGI has clear mod_python support, it won't "have arrived", IMHO. > - Microsoft ASP+Python That is an interesting one. I had originally thought this wouldn't be possible, since ASP is by definition a templating language, meaning that the user's python code is executed at the leaves of an HTML object structure inside the server, and that it wouldn't be possible to circumvent that to provide the flow control that WSGI requires. But there's no reason why a python.asp page could not just consist of a simple document containing nothing but a WSGI invoker. Although it might be difficult to separate out the URL resolution: IIS might insist on resolving URLs to ASP pages itself, meaning that quixote-style step-by-step url resolution might not be possible, for example. I don't use IIS for anything but web-services, so I don't know this detail. > - Twisted > - Zope (2 or 3) I think at least part of the reason why we have so many python web frameworks, and indeed WSGI, is because people want/need something simpler and lighter than these heavyweights. > What do you guys think? If we go to all the framework writers and say > "if you adopt WSGI your framework will automatically run on all of > these platforms", don't you think it's a no-brainer to support it? A lot of framework authors are definitely working on WSGI: I've read about such work in relation to JonPy, CherryPy, SkunkWeb, WebWare, Snakelets, and Python.Web. I'm sure there are others. But if we're going to address perceptions such as this >>>> [WSGI support] not my goal. One of my goals is to have Quixote >>>> work with as many HTTP servers as possible and to make it easy to >>>> switch between them. >> >> Upon that response is probably more cryptic than necessary. What I >> mean is that WSGI support itself means nothing to me. If supporting >> WSGI allows me to achieve my real goal then it will be supported. then we have to demonstrate at least diversity of support: not all framework authors have to time to read PEP-333 in detail. Once WSGI is well established, universality of support won't be far behind. The Blue Sky World is coming: can't you see that patch of blue over there in the South B-) Regards, Alan. From floydophone at gmail.com Fri Nov 26 00:14:08 2004 From: floydophone at gmail.com (Peter Hunt) Date: Fri Nov 26 00:14:10 2004 Subject: [Web-SIG] WSGI adoption In-Reply-To: <5.1.1.6.0.20041125172640.0286c5f0@mail.telecommunity.com> References: <6654eac404112509385ce97e44@mail.gmail.com> <5.1.1.6.0.20041125125555.02756410@mail.telecommunity.com> <6654eac4041125135746e8e0a8@mail.gmail.com> <5.1.1.6.0.20041125172640.0286c5f0@mail.telecommunity.com> Message-ID: <6654eac4041125151452b0d216@mail.gmail.com> Regarding configuration file format, I still think that we should use Python source, as it is easy to parse and easy to specify advanced configuration information. This has already been shown to work: just look at distutils setup scripts. End user editability: we're talking about x = y vs. x = "y" here. I think that Python source code is just as readable as ConfigParser. Sectionability: section.option = "value" I think a more important issue is how they will be deployed. Each configuration file should specify three things: "before", "after", and "middleware". "middleware" is the 'name' of the middleware that this file configures. "before" is a list of the _config files_ which specify middleware that will be called before the one being defined. "after" is the same, except of middleware which will be called after. Just my few ideas. On Thu, 25 Nov 2004 17:34:49 -0500, Phillip J. Eby wrote: > At 04:57 PM 11/25/04 -0500, Peter Hunt wrote: > >Fair enough; we can drop Zope from the priority list. > > > >I'd suggest simply using plain Python as a configuration file format. > >It's just as easy to understand and far more flexible than > >ConfigParser. > > Flexibility of specifying the content isn't really a plus here. End user > editability, and *sectionability* are more important. That is, it should > be easy to have sections for the app, the web server, and general WSGI > information. For that matter, it should be possible for me to include > settings for both mod_python and Twisted in the same configuration file, > such that each one sees only the parts it cares about. That way, an > application developer can minimize the tuning knowledge needed by an > application deployer, for platforms the developer cares about. > > IMO, most of the content of the deployment configuration is either going to > be constants or filenames. For filenames, ConfigParser lets you > interpolate variables, so if you want brevity of expression you can still > do that without going to the full generality of Python. > > > >Also, in terms of configuration files, I think an instance of each > >middleware/application/gateway should get its own configuration file. > > Yes, this is a per-instance deployment file I'm talking about. > > > >While designing this configuration system, we should keep the idea of > >shared hosting in mind, and that the host may want to run certain > >pieces of middleware for everyone. > > I was thinking that part of the configuration passed to an application's > setup would be an optional "next application" value. There are several > ways that could be configured from the deployment file, such as simply > specifying the filename of the deployment file for the next application, or > by embedding a list of deployment files for middleware to be put "above" > the current application. > > I don't have a firm proposal either way for the specific mechanism yet. > > From py-web-sig at xhaus.com Fri Nov 26 00:22:09 2004 From: py-web-sig at xhaus.com (Alan Kennedy) Date: Fri Nov 26 00:23:48 2004 Subject: [Web-SIG] WSGI adoption In-Reply-To: <5.1.1.6.0.20041125172640.0286c5f0@mail.telecommunity.com> References: <5.1.1.6.0.20041125125555.02756410@mail.telecommunity.com> <6654eac404112509385ce97e44@mail.gmail.com> <5.1.1.6.0.20041125125555.02756410@mail.telecommunity.com> <5.1.1.6.0.20041125172640.0286c5f0@mail.telecommunity.com> Message-ID: <41A66921.10601@xhaus.com> [Peter Hunt] >> I'd suggest simply using plain Python as a configuration file format. >> It's just as easy to understand and far more flexible than >> ConfigParser. [Phillip J. Eby] > Flexibility of specifying the content isn't really a plus here. End > user editability, and *sectionability* are more important. That is, it > should be easy to have sections for the app, the web server, and general > WSGI information. For that matter, it should be possible for me to > include settings for both mod_python and Twisted in the same > configuration file, such that each one sees only the parts it cares > about. That way, an application developer can minimize the tuning > knowledge needed by an application deployer, for platforms the developer > cares about. > > IMO, most of the content of the deployment configuration is either going > to be constants or filenames. For filenames, ConfigParser lets you > interpolate variables, so if you want brevity of expression you can > still do that without going to the full generality of Python. Since I don't have a specific proposal myself, I don't want to criticise approaches. But on reading the docs for ConfigParser, I think that it doesn't have encoding support(?). Meaning that configuring internationalised strings will be complex, which will definitely be problematic in a world where most filesystems acccept unicode file names, for example. Python has a simple and clear mechanism for declaring file encodings: it's definitely my favoured option. I understand Carlos' arguments against having end-users edit python files/write programs to configure their servers. But python code containing simple name/value pairs, lists and mappings is also pretty simple to read and write. Maybe we could restrict the structure of such python config files, so that framework authors couldn't force users to learn, for example, metaclasses to configure their software? It needn't be a rigidly-enforced restriction, i.e. checked by an algorithm, but just a line-in-the-sand statement in the spec. Something like "WSGI configuration files may only contain simple python assignments to single objects, lists of objects or dictionaries of objects. They may not contain class definitions, function definitions, import statements, etc, etc."? And lastly, it's got to be said: although we may dislike the awkwardness and rigidity of XML, it is almost universally understood, at all levels of technical ability. It is universally supported in all python environments, and it handles encodings and i18n very gracefully. Regards, Alan. From carribeiro at gmail.com Fri Nov 26 01:35:31 2004 From: carribeiro at gmail.com (Carlos Ribeiro) Date: Fri Nov 26 01:35:33 2004 Subject: [Web-SIG] WSGI adoption In-Reply-To: <41A66921.10601@xhaus.com> References: <6654eac404112509385ce97e44@mail.gmail.com> <5.1.1.6.0.20041125125555.02756410@mail.telecommunity.com> <5.1.1.6.0.20041125172640.0286c5f0@mail.telecommunity.com> <41A66921.10601@xhaus.com> Message-ID: <864d37090411251635721f7980@mail.gmail.com> On Thu, 25 Nov 2004 23:22:09 +0000, Alan Kennedy wrote: > Since I don't have a specific proposal myself, I don't want to criticise > approaches. > > But on reading the docs for ConfigParser, I think that it doesn't have > encoding support(?). Meaning that configuring internationalised strings > will be complex, which will definitely be problematic in a world where > most filesystems acccept unicode file names, for example. > > Python has a simple and clear mechanism for declaring file encodings: > it's definitely my favoured option. Adding encoding support for ConfigParser should not be that difficult. Encoding could be supplied exactly as it is for a Python source file. Also, as far as I understand it, some of the arguments that apply for having encoding support built in into Python do not apply to configuration files; namely, sharing configuration files is not as important as sharing source files. But I may be mistaken. > I understand Carlos' arguments against having end-users edit python > files/write programs to configure their servers. But python code > containing simple name/value pairs, lists and mappings is also pretty > simple to read and write. As soon as you start to use Python files, you open a big door for abuses and weird problems. I fear that things that really should be done on the product code itself will start to be done on the configuration as a kind of "just one more hack". Of course, nobody will ever remember to remove then after some time. > Maybe we could restrict the structure of such python config files, so > that framework authors couldn't force users to learn, for example, > metaclasses to configure their software? It needn't be a > rigidly-enforced restriction, i.e. checked by an algorithm, but just a > line-in-the-sand statement in the spec. Something like "WSGI > configuration files may only contain simple python assignments to single > objects, lists of objects or dictionaries of objects. They may not > contain class definitions, function definitions, import statements, etc, > etc."? Please don't get me wrong. But as soon as you try to impose limitations on syntax, we're back on ConfigParser land again; we have to implement the parser, map values, etc. If we will have to do it, why not reuse what we already have? > And lastly, it's got to be said: although we may dislike the awkwardness > and rigidity of XML, it is almost universally understood, at all levels > of technical ability. It is universally supported in all python > environments, and it handles encodings and i18n very gracefully. There are a number of arguments against XML, the main one being the fact that isn't exactly readable by a human being; also, the fact that it's easily broken by a end-user who may do something as simple as forget to include one slash on the closing tag (and I know how often I do it :-P). Don't get me wrong. XML wasn't done for human consumption; it was conceived for computers, with the nice property that it can be read & conveniently processed by humans for debugging purposes. Simple XML files are readable, but... if all that is needed is a simple file, plain INI is simpler *and* more readable. And as soon as you need to define a more complex structure that needs XML power, it quickly becomes unreadable. -- Carlos Ribeiro Consultoria em Projetos blog: http://rascunhosrotos.blogspot.com blog: http://pythonnotes.blogspot.com mail: carribeiro@gmail.com mail: carribeiro@yahoo.com From pje at telecommunity.com Fri Nov 26 01:42:48 2004 From: pje at telecommunity.com (Phillip J. Eby) Date: Fri Nov 26 01:41:42 2004 Subject: [Web-SIG] WSGI adoption In-Reply-To: <41A66921.10601@xhaus.com> References: <5.1.1.6.0.20041125172640.0286c5f0@mail.telecommunity.com> <5.1.1.6.0.20041125125555.02756410@mail.telecommunity.com> <6654eac404112509385ce97e44@mail.gmail.com> <5.1.1.6.0.20041125125555.02756410@mail.telecommunity.com> <5.1.1.6.0.20041125172640.0286c5f0@mail.telecommunity.com> Message-ID: <5.1.1.6.0.20041125192936.02877360@mail.telecommunity.com> At 11:22 PM 11/25/04 +0000, Alan Kennedy wrote: >[Peter Hunt] > >> I'd suggest simply using plain Python as a configuration file format. > >> It's just as easy to understand and far more flexible than > >> ConfigParser. > >[Phillip J. Eby] > > Flexibility of specifying the content isn't really a plus here. End > > user editability, and *sectionability* are more important. That is, it > > should be easy to have sections for the app, the web server, and general > > WSGI information. For that matter, it should be possible for me to > > include settings for both mod_python and Twisted in the same > > configuration file, such that each one sees only the parts it cares > > about. That way, an application developer can minimize the tuning > > knowledge needed by an application deployer, for platforms the developer > > cares about. > > > > IMO, most of the content of the deployment configuration is either going > > to be constants or filenames. For filenames, ConfigParser lets you > > interpolate variables, so if you want brevity of expression you can > > still do that without going to the full generality of Python. > >Since I don't have a specific proposal myself, I don't want to criticise >approaches. > >But on reading the docs for ConfigParser, I think that it doesn't have >encoding support(?). Meaning that configuring internationalised strings >will be complex, which will definitely be problematic in a world where >most filesystems acccept unicode file names, for example. Hm. Interesting point. I hadn't thought about unicode filenames. I think I'd need a better understanding, though, of how Python deals with string filenames on a platform that uses unicode filenames, before I could suggest a solution. It seems to me that such a solution could potentially be very simple. Indeed, as long as the chosen encoding doesn't interfere with the parsing of the configuration file itself, one could simply use a configuration setting to define the encoding of the values. >And lastly, it's got to be said: although we may dislike the awkwardness >and rigidity of XML, it is almost universally understood, at all levels of >technical ability. I think you *greatly* overestimate its ease of use for a naive user. It's trivially easy to change a single character in XML and break the whole thing, especially if you need to include a <, >, or &. People with HTML experience don't understand why stuff breaks when you mix upper and lower case. IMO, XML is simply not suitable for non-technical users, period. From pje at telecommunity.com Fri Nov 26 01:51:19 2004 From: pje at telecommunity.com (Phillip J. Eby) Date: Fri Nov 26 01:50:15 2004 Subject: [Web-SIG] WSGI adoption In-Reply-To: <6654eac4041125151452b0d216@mail.gmail.com> References: <5.1.1.6.0.20041125172640.0286c5f0@mail.telecommunity.com> <6654eac404112509385ce97e44@mail.gmail.com> <5.1.1.6.0.20041125125555.02756410@mail.telecommunity.com> <6654eac4041125135746e8e0a8@mail.gmail.com> <5.1.1.6.0.20041125172640.0286c5f0@mail.telecommunity.com> Message-ID: <5.1.1.6.0.20041125194254.02877040@mail.telecommunity.com> At 06:14 PM 11/25/04 -0500, Peter Hunt wrote: >Regarding configuration file format, I still think that we should use >Python source, as it is easy to parse and easy to specify advanced >configuration information. This has already been shown to work: just >look at distutils setup scripts. Distutils setup scripts have a different audience: Python programmers. The audience for editing a WSGI application deployment file would include end-users, some of whom might like to use some sort of GUI administration tool to do the editing. >End user editability: we're talking about x = y vs. x = "y" here. Don't forget escaping of quotes, case-sensitivity, and booleans, just for starters. These are all areas where ConfigParser beats Python hands-down for non-programmer users. >I >think that Python source code is just as readable as ConfigParser. > >Sectionability: section.option = "value" And where is 'section' going to come from? Mind you, I'm not married to ConfigParser, but so far it seems to be the best thing, short of defining some new format of our own. (Which I don't think is such a hot idea.) >I think a more important issue is how they will be deployed. Each >configuration file should specify three things: "before", "after", and >"middleware". "middleware" is the 'name' of the middleware that this >file configures. "before" is a list of the _config files_ which >specify middleware that will be called before the one being defined. >"after" is the same, except of middleware which will be called after. Sorry, I don't understand this. Please define what you mean by "called before" and "called after". I also don't get what the 'name' is for. What do you do with it? From floydophone at gmail.com Fri Nov 26 02:04:06 2004 From: floydophone at gmail.com (Peter Hunt) Date: Fri Nov 26 02:04:11 2004 Subject: [Web-SIG] WSGI adoption In-Reply-To: <5.1.1.6.0.20041125194254.02877040@mail.telecommunity.com> References: <6654eac404112509385ce97e44@mail.gmail.com> <5.1.1.6.0.20041125125555.02756410@mail.telecommunity.com> <6654eac4041125135746e8e0a8@mail.gmail.com> <5.1.1.6.0.20041125172640.0286c5f0@mail.telecommunity.com> <6654eac4041125151452b0d216@mail.gmail.com> <5.1.1.6.0.20041125194254.02877040@mail.telecommunity.com> Message-ID: <6654eac404112517044ff38dbb@mail.gmail.com> You have valid points on the python-based configuration files. First, let me go over what a configuration file is. A configuration file defines one instance of middleware. Let me explain what "before" and "after" are. If I have a given middleware "module.middleware2", and before=module.middleware0,module.middleware1, and after=module.middleware3, the gateway will essentially do a call like this: module.middleware3(module.middleware2(module.middleware1(module.middleware0(...)))) Configuration files won't actually specify module.middleware1, they will specify a configuration file which will have the middleware "name" as module.middleware1. That way, we can specify separate parameters to middleware1. On Thu, 25 Nov 2004 19:51:19 -0500, Phillip J. Eby wrote: > At 06:14 PM 11/25/04 -0500, Peter Hunt wrote: > >Regarding configuration file format, I still think that we should use > >Python source, as it is easy to parse and easy to specify advanced > >configuration information. This has already been shown to work: just > >look at distutils setup scripts. > > Distutils setup scripts have a different audience: Python programmers. The > audience for editing a WSGI application deployment file would include > end-users, some of whom might like to use some sort of GUI administration > tool to do the editing. > > > >End user editability: we're talking about x = y vs. x = "y" here. > > Don't forget escaping of quotes, case-sensitivity, and booleans, just for > starters. These are all areas where ConfigParser beats Python hands-down > for non-programmer users. > > > >I > >think that Python source code is just as readable as ConfigParser. > > > >Sectionability: section.option = "value" > > And where is 'section' going to come from? > > Mind you, I'm not married to ConfigParser, but so far it seems to be the > best thing, short of defining some new format of our own. (Which I don't > think is such a hot idea.) > > > >I think a more important issue is how they will be deployed. Each > >configuration file should specify three things: "before", "after", and > >"middleware". "middleware" is the 'name' of the middleware that this > >file configures. "before" is a list of the _config files_ which > >specify middleware that will be called before the one being defined. > >"after" is the same, except of middleware which will be called after. > > Sorry, I don't understand this. Please define what you mean by "called > before" and "called after". I also don't get what the 'name' is for. What > do you do with it? > > From ianb at colorstudy.com Fri Nov 26 02:09:49 2004 From: ianb at colorstudy.com (Ian Bicking) Date: Fri Nov 26 02:09:52 2004 Subject: [Web-SIG] WSGI adoption In-Reply-To: <41A661A2.5090506@xhaus.com> References: <6654eac404112509385ce97e44@mail.gmail.com> <41A661A2.5090506@xhaus.com> Message-ID: <41A6825D.9010509@colorstudy.com> Alan Kennedy wrote: > [Peter Hunt] > > It's going slowly but surely, as I can tell from my Googling. > > Agreed: the google results for "download WSGI server" are disappointing, > with one notable jythonic exception ;-) For now the easiest thing would be for us to all put links in the Python Wiki: http://python.org/moin/WSGIImplementations And maybe the WSGI PEP should link to that (since it's top result and primary reference for "WSGI"). > > I think > > we could speed adoption very quickly if we all got together and > > created stable, tested, proven, and officialy WSGI gateways. > > Definitely. > > I think we have a small perception problem, in that the existing WSGI > servers and utilities are low visibility. They are all a part of another > download, or reside in people's svn repositories, or are small utilities > that don't have documentation, or even readily identifiable names ..... For the most part they are all in an alpha state. Well, at least mine are; moreso, some pieces of WSGIKit are merely placeholders. > I think there are currently three pure python WSGI servers derived from > SimpleHTTPServer. Perhaps someone could take it on themselves to go the > last few steps and give one of them a name, write some simple > WSGI-focussed docs, a setup.py and prepare a download package? > > > I think the following list would be a good place to start, with the > > important ones first and the less-important ones near the bottom: > > > > - CGI > > Definitely the most important. And at least one already exists. All it > requires is a little packaging. > > > - FastCGI > > I think this is more of minority architecture myself. FastCGI is a pain in the butt. But there should be a couple servers along these lines; a multiprocess server and a threaded server. Maybe it can be part of an HTTPServer implementation; perhaps pluggable so that the server could serve HTTP, FastCGI, and some of the FastCGI knockoffs (PCGI, SCGI, mod_webkit, mod_skunk, etc). > > - mod_python > > This is the mainstream. Until WSGI has clear mod_python support, it > won't "have arrived", IMHO. While it should certainly be in there (and shouldn't be too hard), mod_python isn't particularly mainstream IMHO. > > - Microsoft ASP+Python > > That is an interesting one. I had originally thought this wouldn't be > possible, since ASP is by definition a templating language, meaning that > the user's python code is executed at the leaves of an HTML object > structure inside the server, and that it wouldn't be possible to > circumvent that to provide the flow control that WSGI requires. > > But there's no reason why a python.asp page could not just consist of a > simple document containing nothing but a WSGI invoker. Although it might > be difficult to separate out the URL resolution: IIS might insist on > resolving URLs to ASP pages itself, meaning that quixote-style > step-by-step url resolution might not be possible, for example. I don't > use IIS for anything but web-services, so I don't know this detail. I would guess that http://server/page.asp/path/to/component would be easy enough to do. > > - Twisted > > - Zope (2 or 3) > > I think at least part of the reason why we have so many python web > frameworks, and indeed WSGI, is because people want/need something > simpler and lighter than these heavyweights. Twisted is a big install, but it's not actually very heavy. I think it's quite reasonable that we'd use Twisted as a base instead of SimpleHTTPServer, at least in the long run. I'd like to see other access methods so it doesn't require a ProxyPass setup to work with Apache (somehow ProxyPass makes me uncomfortable). And a multi-process option, which could run underneath. The installation size is also a problem, but the Twisted people have been talking about breaking the package up into smaller bits. I feel more comfortable using Twisted for handling sockets and connections than anything we code up on our own; I've never trusted Webware's multi-threaded socket handling. If not Twisted, then Medusa. Zope 3 could be a WSGI application; I don't think the server bits are very interesting. It's still just a Medusa server, right? It would be interesting as a server if you had a WSGI product, so you could attach a WSGI application underneath a Zope 3 server Most of that applies to Zope 2, but Zope 2 has a larger install base and a more opaque installation, so I think it might be more advantageous. Part of WSGI (to me) isn't just to create new lighter frameworks, but to allow for more heterogeneous Python web systems, and to make WSGI-based applications easier to install, maintain, and integrate. If someone makes a really good WSGI webmail app, it would be nice to be able to integrate that inside any system, including Zope. OTOH, Zope isn't a prerequesite for anything, it'd just be nice to see sometime in the future. It's entirely possible I'll do it myself sometime if I want to run a Webware application into Zope; it hasn't happened yet, but most of the pieces are in place. -- Ian Bicking / ianb@colorstudy.com / http://blog.ianbicking.org From pje at telecommunity.com Fri Nov 26 02:34:40 2004 From: pje at telecommunity.com (Phillip J. Eby) Date: Fri Nov 26 02:33:34 2004 Subject: [Web-SIG] WSGI adoption In-Reply-To: <41A6825D.9010509@colorstudy.com> References: <41A661A2.5090506@xhaus.com> <6654eac404112509385ce97e44@mail.gmail.com> <41A661A2.5090506@xhaus.com> Message-ID: <5.1.1.6.0.20041125202848.0284aa90@mail.telecommunity.com> At 07:09 PM 11/25/04 -0600, Ian Bicking wrote: >Twisted is a big install, but it's not actually very heavy. I think it's >quite reasonable that we'd use Twisted as a base instead of >SimpleHTTPServer, at least in the long run. I'd like to see other access >methods so it doesn't require a ProxyPass setup to work with Apache >(somehow ProxyPass makes me uncomfortable). And a multi-process option, >which could run underneath. The installation size is also a problem, but >the Twisted people have been talking about breaking the package up into >smaller bits. Jim Fulton (aka the Zope Pope) is most interested in WSGI for the ability to run Zope under Twisted and mod_python. In the long run, they'd like to also replace their Medusa-based email/FTP/etc. servers with Twisted ones. >Zope 3 could be a WSGI application; There's a prototype application wrapper in the 'zope.app.wsgi' package on the Zope X3 subversion trunk. It's not ready for prime time just yet, though. The thing that made me realize how badly we need a deployment configuration format pretty badly, was when I was trying to help the volunteer who wrote 'zope.app.wsgi', and it became obvious that people were going to have to write Python scripts to glue the thing into a web server. Ultimately, that Just Won't Do, certainly not for Zope's audience. From david at sundayta.com Fri Nov 26 03:10:22 2004 From: david at sundayta.com (Dave Warnock) Date: Fri Nov 26 03:10:45 2004 Subject: [Web-SIG] WSGI adoption In-Reply-To: <41A6825D.9010509@colorstudy.com> References: <6654eac404112509385ce97e44@mail.gmail.com> <41A661A2.5090506@xhaus.com> <41A6825D.9010509@colorstudy.com> Message-ID: <41A6908E.5010605@sundayta.com> Ian, > For now the easiest thing would be for us to all put links in the Python > Wiki: > > http://python.org/moin/WSGIImplementations > > And maybe the WSGI PEP should link to that (since it's top result and > primary reference for "WSGI"). Good, thanks. I like. > FastCGI is a pain in the butt. But there should be a couple servers > along these lines; a multiprocess server and a threaded server. Maybe > it can be part of an HTTPServer implementation; perhaps pluggable so > that the server could serve HTTP, FastCGI, and some of the FastCGI > knockoffs (PCGI, SCGI, mod_webkit, mod_skunk, etc). Ok, but lets get the basic ones of these done first rather than wait until we do it properly ;-) >> > - Twisted >> > - Zope (2 or 3) >> >> I think at least part of the reason why we have so many python web >> frameworks, and indeed WSGI, is because people want/need something >> simpler and lighter than these heavyweights. > > > Twisted is a big install, but it's not actually very heavy. I think > it's quite reasonable that we'd use Twisted as a base instead of > SimpleHTTPServer, at least in the long run. I'd like to see other > access methods so it doesn't require a ProxyPass setup to work with > Apache (somehow ProxyPass makes me uncomfortable). And a multi-process > option, which could run underneath. The installation size is also a > problem, but the Twisted people have been talking about breaking the > package up into smaller bits. Next release of Twisted will be the smaller bits and I agree twisted is a good way to go. > Zope 3 could be a WSGI application; I don't think the server bits are > very interesting. It's still just a Medusa server, right? It would be > interesting as a server if you had a WSGI product, so you could attach a > WSGI application underneath a Zope 3 server > > Most of that applies to Zope 2, but Zope 2 has a larger install base and > a more opaque installation, so I think it might be more advantageous. Agreed 100% Dave -- David Warnock: Sundayta Ltd. http://www.sundayta.com -- Dave Warnock: http://42.blogs.warnock.me.uk From david at sundayta.com Fri Nov 26 03:11:21 2004 From: david at sundayta.com (Dave Warnock) Date: Fri Nov 26 03:11:35 2004 Subject: [Web-SIG] WSGI adoption In-Reply-To: <5.1.1.6.0.20041125194254.02877040@mail.telecommunity.com> References: <5.1.1.6.0.20041125172640.0286c5f0@mail.telecommunity.com> <6654eac404112509385ce97e44@mail.gmail.com> <5.1.1.6.0.20041125125555.02756410@mail.telecommunity.com> <6654eac4041125135746e8e0a8@mail.gmail.com> <5.1.1.6.0.20041125172640.0286c5f0@mail.telecommunity.com> <5.1.1.6.0.20041125194254.02877040@mail.telecommunity.com> Message-ID: <41A690C9.2000909@sundayta.com> Phillip, > Mind you, I'm not married to ConfigParser, but so far it seems to be the > best thing, short of defining some new format of our own. (Which I > don't think is such a hot idea.) I agree. David -- Dave Warnock: http://42.blogs.warnock.me.uk From david at sundayta.com Fri Nov 26 03:31:30 2004 From: david at sundayta.com (Dave Warnock) Date: Fri Nov 26 03:31:32 2004 Subject: [Web-SIG] WSGI adoption In-Reply-To: <5.1.1.6.0.20041125202848.0284aa90@mail.telecommunity.com> References: <41A661A2.5090506@xhaus.com> <6654eac404112509385ce97e44@mail.gmail.com> <41A661A2.5090506@xhaus.com> <5.1.1.6.0.20041125202848.0284aa90@mail.telecommunity.com> Message-ID: <41A69582.1000704@sundayta.com> Phillip, > Jim Fulton (aka the Zope Pope) is most interested in WSGI for the > ability to run Zope under Twisted and mod_python. In the long run, > they'd like to also replace their Medusa-based email/FTP/etc. servers > with Twisted ones. That is great for all these projects. Zope gets a variety of options for deployment. All the others get some heavy load testing done. This is a win win situation. >> Zope 3 could be a WSGI application; > > > There's a prototype application wrapper in the 'zope.app.wsgi' package > on the Zope X3 subversion trunk. It's not ready for prime time just > yet, though. The thing that made me realize how badly we need a > deployment configuration format pretty badly, was when I was trying to > help the volunteer who wrote 'zope.app.wsgi', and it became obvious that > people were going to have to write Python scripts to glue the thing into > a web server. Ultimately, that Just Won't Do, certainly not for Zope's > audience. Agreed. We need configuration and I think we need it in v1.0 of the Pep. Thanks Dave -- David Warnock: Sundayta Ltd. http://www.sundayta.com -- Dave Warnock: http://42.blogs.warnock.me.uk From fumanchu at amor.org Fri Nov 26 08:56:11 2004 From: fumanchu at amor.org (Robert Brewer) Date: Fri Nov 26 08:57:59 2004 Subject: [Web-SIG] WSGI adoption Message-ID: <3A81C87DC164034AA4E2DDFE11D258E32452B9@exchange.hqamor.amorhq.net> Peter Hunt wrote: > >It's going slowly but surely, as I can tell from my Googling. I think > >we could speed adoption very quickly if we all got together and > >created stable, tested, proven, and officialy WSGI gateways. and Phillip J. Eby replied: > ... > That leaves ASP+Python and Zope. ASP has at least two large problems: 1. IIS, as far as I can tell, has no facility for letting a Python application know whether it's being run in a shared process or not (the Low, Medium, High settings for "Application Protection"). To find these out, we'd either have to make deployers enter the value in their config file (and maintain that in sync with IIS), or write some *very* ugly registry hacks to get at the application name and read the protection level. I'm still not sure the latter can be done. I gave up after a couple of days. 2. ASP expects each reachable URL to have a valid file on the server. That means, if you want your user to access "/myapp.htm", there must be a file "myapp.htm" in the root directory of your site (and that folder must map the ".htm" extension to asp.dll). If your site needs 100 URL's, you need 100 such files physically present. IIRC, an ISAPI .dll can get around this, but ASP can't. Not that this can't be worked around; Cation (my framework) has a URL dispatcher which will create the files for you (they're all boilerplate). Robert Brewer MIS Amor Ministries fumanchu@amor.org From floydophone at gmail.com Fri Nov 26 17:41:01 2004 From: floydophone at gmail.com (Peter Hunt) Date: Fri Nov 26 17:41:04 2004 Subject: [Web-SIG] WSGI adoption In-Reply-To: <3A81C87DC164034AA4E2DDFE11D258E32452B9@exchange.hqamor.amorhq.net> References: <3A81C87DC164034AA4E2DDFE11D258E32452B9@exchange.hqamor.amorhq.net> Message-ID: <6654eac4041126084155489a36@mail.gmail.com> Perhaps we need to write an ISAPI DLL? On Thu, 25 Nov 2004 23:56:11 -0800, Robert Brewer wrote: > Peter Hunt wrote: > > >It's going slowly but surely, as I can tell from my Googling. I think > > >we could speed adoption very quickly if we all got together and > > >created stable, tested, proven, and officialy WSGI gateways. > > and Phillip J. Eby replied: > > ... > > That leaves ASP+Python and Zope. > > ASP has at least two large problems: > > 1. IIS, as far as I can tell, has no facility for letting a Python > application know whether it's being run in a shared process or not (the > Low, Medium, High settings for "Application Protection"). To find these > out, we'd either have to make deployers enter the value in their config > file (and maintain that in sync with IIS), or write some *very* ugly > registry hacks to get at the application name and read the protection > level. I'm still not sure the latter can be done. I gave up after a > couple of days. > > 2. ASP expects each reachable URL to have a valid file on the server. > That means, if you want your user to access "/myapp.htm", there must be > a file "myapp.htm" in the root directory of your site (and that folder > must map the ".htm" extension to asp.dll). If your site needs 100 URL's, > you need 100 such files physically present. IIRC, an ISAPI .dll can get > around this, but ASP can't. Not that this can't be worked around; Cation > (my framework) has a URL dispatcher which will create the files for you > (they're all boilerplate). > > > Robert Brewer > MIS > Amor Ministries > fumanchu@amor.org > From titus at caltech.edu Sat Nov 27 09:16:23 2004 From: titus at caltech.edu (Titus Brown) Date: Sat Nov 27 09:16:26 2004 Subject: [Web-SIG] Quixote/SCGI -- adapters for WSGI. Message-ID: <20041127081623.GA7387@caltech.edu> Hi all, I spent some time today implementing a generic WSGI <--> Quixote application adapter ('QWIP') and a generic SCGI <--> WSGI server adapter ('SWAP') [0]. Respectively these allow you to easily run any Quixote application inside of a WSGI server, and also run any WSGI application inside of a SCGI server. See http://issola.caltech.edu/~t/transfer/qwsgi/README.html for info and grab the source (+ some examples) at http://issola.caltech.edu/~t/transfer/qwip-and-swap-26.11.04.tar.gz I'd like to thank Phillip Eby for writing such a nice PEP; it really made life easier, and anything I've missed is solely through my own carelessness! As far as I can tell w/o more serious testing, these should be fully functional adapters. I started with the simple CGI code examples in the PEP & branched out from there. QWIP, the application adapter for Quixote, runs under both SWAP and the CGI adapter in the PEP. SWAP executes all of my QWIP test programs as well as the simple "hello, world" application code in the PEP. I would be interested in finding out how well these work for other WSGI-ers, and I'm happy to serve as a collection point for problem reports or patches. If the code is useful hopefully I can pass it on to the involved projects... cheers, --titus [0] http://www.advogato.org/person/titus/diary.html?start=9 for the commentary. From ianb at colorstudy.com Sun Nov 28 10:46:20 2004 From: ianb at colorstudy.com (Ian Bicking) Date: Sun Nov 28 10:46:21 2004 Subject: [Web-SIG] Config system Message-ID: <41A99E6C.7050103@colorstudy.com> I've been doing some more work on a config file loader, part of WSGIKit: svn://colorstudy.com/trunk/WSGIKit It's in wsgikit.config -- lazyloader in particular. It has some features that I think are useful: * Uses .ini syntax, i.e., easy to edit. Doesn't use Python expressions, i.e., you don't need to quote all strings. * Allows nested structures, in the form of dotted config keys. Sections are just common prefixes for these keys. I.e, these are equivalent: [vhost(my.host.com)] document_root = /var/www and: vhost(my.host.com).document_root = /var/www Parenthesis quote the values, so names aren't normalized inside parenthesis and .'s aren't interpreted. * It saves information on where each configuration value comes from, so you don't have to check for validity up-front. config.inischema was an experiment defining an up-front schema and requiring validity whent the config file was loaded. This wouldn't work for WSGI, because we don't know what middleware is going to look at the configuration values up front. But since it saves information, you can do validation at a late stage and still give error messages that give the filename and line number of the error. * You can load several config files, each one overriding the previous ones, but with the previous values still visible if they weren't overrided. This also works for nested dictionaries. You can also get a list of all values for a key in all the config files (as well as the duplicated keys in a single config file). Though in most cases I think it's best not to use duplicate keys, since key names can contain more information than in some systems (like Apache conf files). E.g., "types.(text/plain).filter = myfilterapp", or "options.autoindexing = off". * You can merge configuration values into new locations in a config file. A common example would be virtual host configuration -- you can take a virtual host section and merge it into the main server section. You have to be careful about making the right copies, but the only thing that's destructively mutated is the list of shadowed dictionaries; so if two configurations share dictionaries it is safe. * There's some possibility for writing config files out with changed values. I haven't really thought it out completely, but it keeps enough information to make it possible. The lazyiniparser module that lazyloader uses can write modules out with little information loss (mostly whitespace; comments are preserved and names aren't normalized). With lazyloader it's a little more confusing, because it's not clear with the dictionary syntax which file would get the new or changed setting, or when it would get written. It has a bunch of tests, though it's not exhaustive (using py.test; http://codespeak.net/py) and it has some docstrings. There's nothing yet to actually integrate it with WSGI, and I'm probably going to first use it on a non-WSGI project. But I think the integration should be fairly simple, just putting the objects in a known location in the WSGI environ. -- Ian Bicking / ianb@colorstudy.com / http://blog.ianbicking.org From david at sundayta.com Sun Nov 28 15:06:55 2004 From: david at sundayta.com (Dave Warnock) Date: Sun Nov 28 15:07:08 2004 Subject: [Web-SIG] Config system In-Reply-To: <41A99E6C.7050103@colorstudy.com> References: <41A99E6C.7050103@colorstudy.com> Message-ID: <41A9DB7F.8010300@sundayta.com> Ian, > I've been doing some more work on a config file loader, part of WSGIKit: > svn://colorstudy.com/trunk/WSGIKit > > It's in wsgikit.config -- lazyloader in particular. > > It has some features that I think are useful: Sounds cool. My feeling is that we should have a defined standard behaviour (format of configuration file, consistent appearance of the results inside a wsgi application etc) and then allow a variety of implementations. So can what you and Phillip are doing and merge out of that something so that the choice of config implementation does not require changing configuration file or application. By the way your webserver at colorstudy seems to be down. Regards Dave -- Dave Warnock: http://42.blogs.warnock.me.uk From ianb at colorstudy.com Sun Nov 28 21:19:11 2004 From: ianb at colorstudy.com (Ian Bicking) Date: Sun Nov 28 21:19:12 2004 Subject: [Web-SIG] Config system In-Reply-To: <41A9DB7F.8010300@sundayta.com> References: <41A99E6C.7050103@colorstudy.com> <41A9DB7F.8010300@sundayta.com> Message-ID: <41AA32BF.8020001@colorstudy.com> Dave Warnock wrote: >> I've been doing some more work on a config file loader, part of >> WSGIKit: svn://colorstudy.com/trunk/WSGIKit >> >> It's in wsgikit.config -- lazyloader in particular. >> >> It has some features that I think are useful: > > > Sounds cool. My feeling is that we should have a defined standard > behaviour (format of configuration file, consistent appearance of the > results inside a wsgi application etc) and then allow a variety of > implementations. I don't really know if it's meaningful to have multiple implementations unless they each have some reason for existing. With WSGI there's obviously a reason for multiple implementations. I'm having a hard time seeing what meaningful alternate implementations there would be for this. Well, I can imagine other config file formats, like XML. There's no hooks for adding a new parser, but it should really be fairly easy. There's actually several XML formats I could imagine, depending on how uniform a schema you want (Java configs being on the uniform end). But other formats would be harder. For instance, YAML is typed (i.e., a configuration value becomes an integer or a string at parse time), which doesn't really work with the rest of the system. (Something that looks like YAML but doesn't deal with types would be okay.) I'm not sure about ZConfig. In many ways, the semantics and features of this system require the implementation to look like it does. You could change trivial parts -- for instance, the way configuration keys are split up for creating hierarchies, or how sections relate to the keys contained in them -- but those aren't the interesting or challenging parts (IMHO). Alternatively, we could define configuration abstractly enough that multiple novel implementations would be possible. But I'm not sure that is actually possible. > So can what you and Phillip are doing and merge out of that something so > that the choice of config implementation does not require changing > configuration file or application. > > By the way your webserver at colorstudy seems to be down. Yeah, I haven't been able to install PyCS on my new server, so I'm trying to set up a new blog system I've been thinking about, of which configuration is a part ;) -- Ian Bicking / ianb@colorstudy.com / http://blog.ianbicking.org From rodsenra at gpr.com.br Mon Nov 29 13:06:47 2004 From: rodsenra at gpr.com.br (Rodrigo Dias Arruda Senra) Date: Mon Nov 29 13:06:52 2004 Subject: [Web-SIG] WSGI adoption In-Reply-To: <6654eac4041125151452b0d216@mail.gmail.com> References: <6654eac404112509385ce97e44@mail.gmail.com> <5.1.1.6.0.20041125125555.02756410@mail.telecommunity.com> <6654eac4041125135746e8e0a8@mail.gmail.com> <5.1.1.6.0.20041125172640.0286c5f0@mail.telecommunity.com> <6654eac4041125151452b0d216@mail.gmail.com> Message-ID: <20041129100647.00004bb8@Fenix> [ Peter Hunt ]: -------------------------------------------------------- > Regarding configuration file format, I still think that we should use > Python source, as it is easy to parse and easy to specify advanced > configuration information. This has already been shown to work: just > look at distutils setup scripts. Since Zope came up recently in this thread, have anybody considered using ZConfig as a configuration engine ? I see the following benefits: - code reuse - rich configuration options - extensible - easy to use - supports XML sections (not compulsory) best regards, Rod Senra rodsenra@gpr.com.br From pje at telecommunity.com Mon Nov 29 16:16:54 2004 From: pje at telecommunity.com (Phillip J. Eby) Date: Mon Nov 29 16:17:55 2004 Subject: [Web-SIG] WSGI adoption In-Reply-To: <20041129100647.00004bb8@Fenix> References: <6654eac4041125151452b0d216@mail.gmail.com> <6654eac404112509385ce97e44@mail.gmail.com> <5.1.1.6.0.20041125125555.02756410@mail.telecommunity.com> <6654eac4041125135746e8e0a8@mail.gmail.com> <5.1.1.6.0.20041125172640.0286c5f0@mail.telecommunity.com> <6654eac4041125151452b0d216@mail.gmail.com> Message-ID: <5.1.1.6.0.20041129101329.02100bd0@mail.telecommunity.com> At 10:06 AM 11/29/04 -0200, Rodrigo Dias Arruda Senra wrote: >[ Peter Hunt ]: >-------------------------------------------------------- > > Regarding configuration file format, I still think that we should use > > Python source, as it is easy to parse and easy to specify advanced > > configuration information. This has already been shown to work: just > > look at distutils setup scripts. > >Since Zope came up recently in this thread, have anybody considered >using ZConfig as a configuration engine ? > >I see the following benefits: > > - code reuse > - rich configuration options > - extensible > - easy to use > - supports XML sections (not compulsory) ZConfig isn't a bad format overall, but it does have a rather serious problem for the deployment format: it expects to have a fixed schema, which means there's not really a good way to have a file that contains information for one server to use, and another server to ignore, while there's also information for the app that the server ignores and vice versa. You can of course hack its schema mechanism to accommodate such a format, but at that point you've also removed all of the validation and processing that it does, so you might as well go back to plain .ini format, which at least has a parser in the standard library. From janssen at parc.com Mon Nov 29 19:29:07 2004 From: janssen at parc.com (Bill Janssen) Date: Mon Nov 29 19:29:34 2004 Subject: [Web-SIG] WSGI adoption In-Reply-To: Your message of "Thu, 25 Nov 2004 14:50:10 PST." <41A661A2.5090506@xhaus.com> Message-ID: <04Nov29.102914pst."58617"@synergy1.parc.xerox.com> > I think at least part of the reason why we have so many python web > frameworks, and indeed WSGI, is because people want/need something > simpler and lighter than these heavyweights. Yep. That's why I use Medusa, which should be added to the list. Bill From janssen at parc.com Mon Nov 29 19:31:39 2004 From: janssen at parc.com (Bill Janssen) Date: Mon Nov 29 19:32:04 2004 Subject: [Web-SIG] WSGI adoption In-Reply-To: Your message of "Thu, 25 Nov 2004 18:11:21 PST." <41A690C9.2000909@sundayta.com> Message-ID: <04Nov29.103149pst."58617"@synergy1.parc.xerox.com> I agree. Bill > Phillip, > > > Mind you, I'm not married to ConfigParser, but so far it seems to be the > > best thing, short of defining some new format of our own. (Which I > > don't think is such a hot idea.) > > I agree. > > David > -- > Dave Warnock: http://42.blogs.warnock.me.uk > > _______________________________________________ > 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/janssen%40parc.com From py-web-sig at xhaus.com Mon Nov 29 20:46:02 2004 From: py-web-sig at xhaus.com (Alan Kennedy) Date: Mon Nov 29 20:49:23 2004 Subject: [Web-SIG] WSGI adoption In-Reply-To: <5.1.1.6.0.20041129101329.02100bd0@mail.telecommunity.com> References: <6654eac4041125151452b0d216@mail.gmail.com> <6654eac404112509385ce97e44@mail.gmail.com> <5.1.1.6.0.20041125125555.02756410@mail.telecommunity.com> <6654eac4041125135746e8e0a8@mail.gmail.com> <5.1.1.6.0.20041125172640.0286c5f0@mail.telecommunity.com> <6654eac4041125151452b0d216@mail.gmail.com> <5.1.1.6.0.20041129101329.02100bd0@mail.telecommunity.com> Message-ID: <41AB7C7A.1060602@xhaus.com> [Phillip J. Eby] > ZConfig isn't a bad format overall, but it does have a rather serious > problem for the deployment format: it expects to have a fixed schema, > which means there's not really a good way to have a file that contains > information for one server to use, and another server to ignore, while > there's also information for the app that the server ignores and vice > versa. > > You can of course hack its schema mechanism to accommodate such a > format, but at that point you've also removed all of the validation and > processing that it does, so you might as well go back to plain .ini > format, which at least has a parser in the standard library. I did a little reading about ConfigParser. I found the following interesting thread from python-dev last month. http://mail.python.org/pipermail/python-dev/2004-October/049167.html Which includes the following quotes """ [David Goodger] >>> Ideally, the docs should discourage further non-string uses and >>> advise that ConfigParser will be string only for Py3.0. [Brett Cannon] >> Yikes! Can't we just toss it for Py3K? This module just hasn't >> held up, and exposes a really poor model even for .ini-style >> configuration files. [Guido van Rossum] > Hear hear. > What sucks (relatively) is the specific way that ConfigParser > provides access to .ini files; I always end up writing a wrapping > layer around it. """ The outcome of that discussion was a ConfigParser shootout, which you can read here http://www.python.org/moin/ConfigParserShootout So it seems that 1. There are a number of problems with ConfigParser. 2. These problems are sufficiently bad that GvR has declared he'd be happy to consider replacements. 3. Even if we did use ConfigParser, it still doesn't solve the lack of encoding support. 4. Other people are having exactly the same problems deciding how best to approach configuration. It is also interesting to note GvR's dislike of XML """ The most important user of a config file is not the programmer who has to get data out of it; the most important user is the user who has to edit the config file. The outrageous verbosity of XML makes the above example a complete usability liability. Now, if you're talking about config files that represent options that the user edits in a convenient application-specific options dialog, that's a different story; I think XML is well-suited for that; but I'm talking about the classic configuration file pattern where you use your favorite flat-file text editor to edit the options file. In that situation, using XML is insane. """ http://mail.python.org/pipermail/python-dev/2004-October/049179.html Regards, Alan. From pje at telecommunity.com Mon Nov 29 22:29:41 2004 From: pje at telecommunity.com (Phillip J. Eby) Date: Mon Nov 29 22:30:53 2004 Subject: [Web-SIG] WSGI adoption In-Reply-To: <41AB7C7A.1060602@xhaus.com> References: <5.1.1.6.0.20041129101329.02100bd0@mail.telecommunity.com> <6654eac4041125151452b0d216@mail.gmail.com> <6654eac404112509385ce97e44@mail.gmail.com> <5.1.1.6.0.20041125125555.02756410@mail.telecommunity.com> <6654eac4041125135746e8e0a8@mail.gmail.com> <5.1.1.6.0.20041125172640.0286c5f0@mail.telecommunity.com> <6654eac4041125151452b0d216@mail.gmail.com> <5.1.1.6.0.20041129101329.02100bd0@mail.telecommunity.com> Message-ID: <5.1.1.6.0.20041129160054.037e1210@mail.telecommunity.com> At 07:46 PM 11/29/04 +0000, Alan Kennedy wrote: >1. There are a number of problems with ConfigParser. >2. These problems are sufficiently bad that GvR has declared he'd be happy >to consider replacements. My understanding is that the problems are with the API exposed by ConfigParser, not the format or even its implementation per se. You will notice that Guido says he "always end[s] up writing a wrapping layer around it", not that he doesn't use it! >3. Even if we did use ConfigParser, it still doesn't solve the lack of >encoding support. True, but entirely manageable for any 8-bit encoding that doesn't require escaping for the characters (such as #, ; , [, =, ], :, and whitespace) that ConfigParser uses for syntax. IOW, the various Latin codings and UTF-8 are all fine. >4. Other people are having exactly the same problems deciding how best to >approach configuration. Actually, they aren't. The ConfigParserShootout has expanded scope tremendously over the original Python-Dev discussion, which was much more about API than format. The needs for a WSGI deployment format are much more straightforward. The format MUST be: * Easy for non-programmer users to read, write, and edit (which implies a variety of more detailed requirements, such as case-insensitivity for configuration keys, and a lack of excessive quoting or escaping) * Extensible, such that programs can ignore parts that are not intended for them * Able to represent filenames, strings, numbers, and boolean flags. The format SHOULD be: * Easy for a GUI or other tool to edit or generate To me, the .ini syntax's only failing in these requirements so far is that an encoding would need to be specified for strings. Whether the ConfigParser library itself should be used or not, I don't know. Its advantages are: * It's been in the standard library a long time, meaning it's available on the platforms of interest for WSGI * It handles booleans in a user-friendly fashion, at least for English-speaking users. * It allows string interpolation for the hackerly types who don't like repeating themselves Its disadvantages are: * Implementation has changed a lot over its history * Documentation is accused of being "handwavy" * Format is not rigorously defined Of course, I would be fine with us rigorously defining a format that met the requirements. One other possibility I can see, would be the Java properties file format, or something similar to it. From ianb at colorstudy.com Mon Nov 29 23:15:15 2004 From: ianb at colorstudy.com (Ian Bicking) Date: Mon Nov 29 23:18:38 2004 Subject: [Web-SIG] WSGI adoption In-Reply-To: <5.1.1.6.0.20041129160054.037e1210@mail.telecommunity.com> References: <5.1.1.6.0.20041129101329.02100bd0@mail.telecommunity.com> <6654eac4041125151452b0d216@mail.gmail.com> <6654eac404112509385ce97e44@mail.gmail.com> <5.1.1.6.0.20041125125555.02756410@mail.telecommunity.com> <6654eac4041125135746e8e0a8@mail.gmail.com> <5.1.1.6.0.20041125172640.0286c5f0@mail.telecommunity.com> <6654eac4041125151452b0d216@mail.gmail.com> <5.1.1.6.0.20041129101329.02100bd0@mail.telecommunity.com> <5.1.1.6.0.20041129160054.037e1210@mail.telecommunity.com> Message-ID: <41AB9F73.4070801@colorstudy.com> Phillip J. Eby wrote: >> 3. Even if we did use ConfigParser, it still doesn't solve the lack of >> encoding support. > > > True, but entirely manageable for any 8-bit encoding that doesn't > require escaping for the characters (such as #, ; , [, =, ], :, and > whitespace) that ConfigParser uses for syntax. IOW, the various Latin > codings and UTF-8 are all fine. Well, it returns text as 8-bit strings, not as unicode strings. I think Alan wants unicode. I imagine it would be easy enough to add -- maybe enough just to open the file with an encoding specified (though being able to detect the encoding would be better). But never using unicode strings, I seldom know what the Right Thing is for unicode. Or, if applied as a wrapper, you could decode all the strings after they've been loaded. Maybe that's what you were thinking? >> 4. Other people are having exactly the same problems deciding how best >> to approach configuration. > > > Actually, they aren't. The ConfigParserShootout has expanded scope > tremendously over the original Python-Dev discussion, which was much > more about API than format. The needs for a WSGI deployment format are > much more straightforward. Well, it's not the ConfigParserShootout's fault that more persistent, extended discussion moved there. That was the idea of the wiki page. It might not be representative of everyone's feelings, but it's representative of something. > The format MUST be: > > * Easy for non-programmer users to read, write, and edit (which implies > a variety of more detailed requirements, such as case-insensitivity for > configuration keys, and a lack of excessive quoting or escaping) > * Extensible, such that programs can ignore parts that are not intended > for them Extensibility also requires (IMHO) the layering of multiple configuration files**. Maybe ConfigParser's model of just overwriting old values with every read() is sufficient; though at least it should have a .copy() method if it's going to destructively read values. > * Able to represent filenames, strings, numbers, and boolean flags. I think it's easiest that it simply have string values, without any "native" data types. This is how ConfigParser works, though it also happens to include convenience methods that also do conversion (in contrast to YAML, where data types are built into the config file format) > The format SHOULD be: > > * Easy for a GUI or other tool to edit or generate ConfigParser does poorly at this; if I was to do this with ConfigParser you'd really end up doing some sort of funny thing where you made a separate parser that would look for the point in the file you want to add a key, then do so, and modify ConfigParser so it kept track of the changes that were made to it; ConfigParser itself doesn't facilitate this at all. > To me, the .ini syntax's only failing in these requirements so far is > that an encoding would need to be specified for strings. > > Whether the ConfigParser library itself should be used or not, I don't > know. Its advantages are: > > * It's been in the standard library a long time, meaning it's available > on the platforms of interest for WSGI Because no one is (or would) propose any alternative other than a plain-Python module, it's not a big deal to distribute it separately. Especially if there are version issues with old versions of Python and ConfigParser. (I'm not sure if there is, but if we want to enhance ConfigParser even slightly then there will be) > * It handles booleans in a user-friendly fashion, at least for > English-speaking users. That's fairly trivial functionality. At least it's trivial when you don't have native types, i.e., you know ahead of time (or at runtime) what values are to be interpreted as booleans. > * It allows string interpolation for the hackerly types who don't like > repeating themselves People seem unhappy with this feature. At least there were several people in the python-dev who felt this way. The fact that there's a "more sane" version of this (SafeConfigParser) makes it seem like a questionable feature. It's also useful, so I'm not entirely sure what to make of it. But then if we go down that path, conditionals (#ifdef-style) are also very useful, but soon we need a whole programming language. Substitutions can also be applied to values after they are loaded. > Its disadvantages are: > > * Implementation has changed a lot over its history > > * Documentation is accused of being "handwavy" Maybe because it has a few too many options and a couple different interfaces (the different classes). Mostly I think it's an ordering problem; RawConfigParser should be completely explained (and shouldn't be too hard to explain), and the other parsers > * Format is not rigorously defined It's not rigorous, but is it ambiguous or otherwise problematic? When I reimplemented the parser (wsgikit.config.iniparser) I didn't notice any ambiguities, except maybe in terms of error conditions. Well, there's maybe a question about how continuation lines should be interpreted. Should all leading whitespace be chopped off? Should newlines remain? > Of course, I would be fine with us rigorously defining a format that met > the requirements. > > One other possibility I can see, would be the Java properties file > format, or something similar to it. That's just an XML format, right? A painfully verbose format if I remember, even for XML. -- Ian Bicking / ianb@colorstudy.com / http://blog.ianbicking.org From pje at telecommunity.com Tue Nov 30 00:12:02 2004 From: pje at telecommunity.com (Phillip J. Eby) Date: Tue Nov 30 00:13:18 2004 Subject: [Web-SIG] WSGI adoption In-Reply-To: <41AB9F73.4070801@colorstudy.com> References: <5.1.1.6.0.20041129160054.037e1210@mail.telecommunity.com> <5.1.1.6.0.20041129101329.02100bd0@mail.telecommunity.com> <6654eac4041125151452b0d216@mail.gmail.com> <6654eac404112509385ce97e44@mail.gmail.com> <5.1.1.6.0.20041125125555.02756410@mail.telecommunity.com> <6654eac4041125135746e8e0a8@mail.gmail.com> <5.1.1.6.0.20041125172640.0286c5f0@mail.telecommunity.com> <6654eac4041125151452b0d216@mail.gmail.com> <5.1.1.6.0.20041129101329.02100bd0@mail.telecommunity.com> <5.1.1.6.0.20041129160054.037e1210@mail.telecommunity.com> Message-ID: <5.1.1.6.0.20041129180203.02604e50@mail.telecommunity.com> At 04:15 PM 11/29/04 -0600, Ian Bicking wrote: >Or, if applied as a wrapper, you could decode all the strings after >they've been loaded. Maybe that's what you were thinking? Yes, I meant decode-after-load, specifying the encoding as one of the configuration variables. >Extensibility also requires (IMHO) the layering of multiple configuration >files**. Eh? >>The format SHOULD be: >>* Easy for a GUI or other tool to edit or generate > >ConfigParser does poorly at this; if I was to do this with ConfigParser >you'd really end up doing some sort of funny thing where you made a >separate parser that would look for the point in the file you want to add >a key, then do so, and modify ConfigParser so it kept track of the changes >that were made to it; ConfigParser itself doesn't facilitate this at all. I didn't mean "edit while preserving structure and comments", only "edit while preserving semantics". >>To me, the .ini syntax's only failing in these requirements so far is >>that an encoding would need to be specified for strings. >>Whether the ConfigParser library itself should be used or not, I don't >>know. Its advantages are: >>* It's been in the standard library a long time, meaning it's available >>on the platforms of interest for WSGI > >Because no one is (or would) propose any alternative other than a >plain-Python module, it's not a big deal to distribute it separately. >Especially if there are version issues with old versions of Python and >ConfigParser. (I'm not sure if there is, but if we want to enhance >ConfigParser even slightly then there will be) If we do anything other than just say, "Use ConfigParser", then IMO we need to spell out the semantics, and create a clean implementation of those semantics. >>* It allows string interpolation for the hackerly types who don't like >>repeating themselves > >People seem unhappy with this feature. At least there were several people >in the python-dev who felt this way. The fact that there's a "more sane" >version of this (SafeConfigParser) makes it seem like a questionable >feature. It's also useful, so I'm not entirely sure what to make of >it. But then if we go down that path, conditionals (#ifdef-style) are >also very useful, but soon we need a whole programming language. The specific use case I have in mind for that feature is merely avoiding the repetition of lengthy base directory names. However, it's not a necessity. >>Of course, I would be fine with us rigorously defining a format that met >>the requirements. >>One other possibility I can see, would be the Java properties file >>format, or something similar to it. > >That's just an XML format, right? A painfully verbose format if I >remember, even for XML. I'm referring to this format, which is even simpler than ConfigParser, and rather more rigorously defined, including the expected encoding and support for Unicode: http://java.sun.com/j2se/1.3/docs/api/java/util/Properties.html#load(java.io.InputStream) It does have some features that are less desirable, like case-sensitivity, backslash-escapes, and the fact that its encoding is only friendly to Latin-1 users. Also, it's likely to become quite verbose if a given application or server defines lots of configuration keys. On the other hand, it could be a good thing to discourage people from putting lots of application configuration in the deployment file, instead of just using it primarily to locate to the application's own configuration files. From janssen at parc.com Tue Nov 30 01:00:57 2004 From: janssen at parc.com (Bill Janssen) Date: Tue Nov 30 01:01:18 2004 Subject: [Web-SIG] WSGI adoption In-Reply-To: Your message of "Mon, 29 Nov 2004 13:29:41 PST." <5.1.1.6.0.20041129160054.037e1210@mail.telecommunity.com> Message-ID: <04Nov29.160101pst."58617"@synergy1.parc.xerox.com> > One other possibility I can see, would be the Java properties file format, > or something similar to it. Which is essentially the ConfigParser format, but without the saving grace of sections. I see no reason to avoid the ConfigParser. Bill From ianb at colorstudy.com Tue Nov 30 03:45:26 2004 From: ianb at colorstudy.com (Ian Bicking) Date: Tue Nov 30 03:45:27 2004 Subject: [Web-SIG] WSGI adoption In-Reply-To: <5.1.1.6.0.20041129180203.02604e50@mail.telecommunity.com> References: <5.1.1.6.0.20041129160054.037e1210@mail.telecommunity.com> <5.1.1.6.0.20041129101329.02100bd0@mail.telecommunity.com> <6654eac4041125151452b0d216@mail.gmail.com> <6654eac404112509385ce97e44@mail.gmail.com> <5.1.1.6.0.20041125125555.02756410@mail.telecommunity.com> <6654eac4041125135746e8e0a8@mail.gmail.com> <5.1.1.6.0.20041125172640.0286c5f0@mail.telecommunity.com> <6654eac4041125151452b0d216@mail.gmail.com> <5.1.1.6.0.20041129101329.02100bd0@mail.telecommunity.com> <5.1.1.6.0.20041129160054.037e1210@mail.telecommunity.com> <5.1.1.6.0.20041129180203.02604e50@mail.telecommunity.com> Message-ID: <41ABDEC6.9040502@colorstudy.com> Phillip J. Eby wrote: > At 04:15 PM 11/29/04 -0600, Ian Bicking wrote: > >> Or, if applied as a wrapper, you could decode all the strings after >> they've been loaded. Maybe that's what you were thinking? > > > Yes, I meant decode-after-load, specifying the encoding as one of the > configuration variables. > > >> Extensibility also requires (IMHO) the layering of multiple >> configuration files**. > > > Eh? Well, maybe we're thinking about this differently. I think it's pycoimportant to be able to take several files and combine them for configuration; e.g., site and application configuration files. But just for deployment, that's probably not as interesting. It depends how expansive "deployment" is. Maybe it's fine if the deployment configuration is functionally simple, if we can reload it into a more complete system later. In which case it would be good to define the format well. >>> The format SHOULD be: >>> * Easy for a GUI or other tool to edit or generate >> >> >> ConfigParser does poorly at this; if I was to do this with >> ConfigParser you'd really end up doing some sort of funny thing where >> you made a separate parser that would look for the point in the file >> you want to add a key, then do so, and modify ConfigParser so it kept >> track of the changes that were made to it; ConfigParser itself doesn't >> facilitate this at all. > > > I didn't mean "edit while preserving structure and comments", only "edit > while preserving semantics". If the file is meant to be human editable, it should preserve some structure in case of editing. I can't stand tools that mangle your files, unless that tool truly *owns* the file (e.g., some custom XML file). >>> To me, the .ini syntax's only failing in these requirements so far is >>> that an encoding would need to be specified for strings. >>> Whether the ConfigParser library itself should be used or not, I >>> don't know. Its advantages are: >>> * It's been in the standard library a long time, meaning it's >>> available on the platforms of interest for WSGI >> >> >> Because no one is (or would) propose any alternative other than a >> plain-Python module, it's not a big deal to distribute it separately. >> Especially if there are version issues with old versions of Python and >> ConfigParser. (I'm not sure if there is, but if we want to enhance >> ConfigParser even slightly then there will be) > > > If we do anything other than just say, "Use ConfigParser", then IMO we > need to spell out the semantics, and create a clean implementation of > those semantics. iniparser is one implementation of semantics, though not particularly formally specified. If I was to specify it, I think it'd go like: A file is parsed line-by-line. A section is a line starting with "[", ignoring whitespace. This line must end with "]" (ignoring whitespace), and the whitespace-stripped contents are the "section name". The beginning of one section is the end of the last section; there is no explicit way to end a section. A comment is a line starting with # or ;, ignoring whitespace. Blank lines are ignored. An assignment is any other line. An assignment must contain a = or a :; the first of these characters found is used. The text before the separator, stripped of whitespace, is the key name. The text after, stripped of whitespace, is the key value. An assignment can span multiple lines if the following lines are indented, i.e., start with whitespace. The first unindented line (i.e., a line that doesn't start with whitespace) or the first blank line ends the assignment. The text is the concatenation of all lines. (Here's where I'm unclear; including newlines? What happens to the leading whitespace?) Well, that probably doesn't match ConfigParser entirely. I believe it requires that all sections and assignments have non-whitespace in the first column, but I'm not sure about that. It also still doesn't deal with encoding, or allow for any kind of quoting. >>> * It allows string interpolation for the hackerly types who don't >>> like repeating themselves >> >> >> People seem unhappy with this feature. At least there were several >> people in the python-dev who felt this way. The fact that there's a >> "more sane" version of this (SafeConfigParser) makes it seem like a >> questionable feature. It's also useful, so I'm not entirely sure what >> to make of it. But then if we go down that path, conditionals >> (#ifdef-style) are also very useful, but soon we need a whole >> programming language. > > > The specific use case I have in mind for that feature is merely avoiding > the repetition of lengthy base directory names. However, it's not a > necessity. The judicious use of relative paths can help. I.e., specify what each path is relative to, and some paths in the configuration may be relative to other paths. >>> Of course, I would be fine with us rigorously defining a format that >>> met the requirements. >>> One other possibility I can see, would be the Java properties file >>> format, or something similar to it. >> >> >> That's just an XML format, right? A painfully verbose format if I >> remember, even for XML. > > > I'm referring to this format, which is even simpler than ConfigParser, > and rather more rigorously defined, including the expected encoding and > support for Unicode: > > http://java.sun.com/j2se/1.3/docs/api/java/util/Properties.html#load(java.io.InputStream) It's nice in that it can easily be used with any unicode string value, though its keys aren't as flexible. > It does have some features that are less desirable, like > case-sensitivity, backslash-escapes, and the fact that its encoding is > only friendly to Latin-1 users. Also, it's likely to become quite > verbose if a given application or server defines lots of configuration > keys. On the other hand, it could be a good thing to discourage people > from putting lots of application configuration in the deployment file, > instead of just using it primarily to locate to the application's own > configuration files. -- Ian Bicking / ianb@colorstudy.com / http://blog.ianbicking.org From pje at telecommunity.com Tue Nov 30 07:07:06 2004 From: pje at telecommunity.com (Phillip J. Eby) Date: Tue Nov 30 07:08:37 2004 Subject: [Web-SIG] WSGI adoption In-Reply-To: <04Nov29.160101pst."58617"@synergy1.parc.xerox.com> References: Message-ID: <5.1.1.6.0.20041130010544.0254e5e0@mail.telecommunity.com> At 04:00 PM 11/29/04 -0800, Bill Janssen wrote: > > One other possibility I can see, would be the Java properties file format, > > or something similar to it. > >Which is essentially the ConfigParser format, but without the saving >grace of sections. But with a rigorous format definition, including a precise definition of how Unicode is handled. (OTOH, it's not exactly Unicode-friendly, either.) From py-web-sig at xhaus.com Tue Nov 30 09:59:25 2004 From: py-web-sig at xhaus.com (Alan Kennedy) Date: Tue Nov 30 10:09:43 2004 Subject: [Web-SIG] WSGI adoption In-Reply-To: <41AB9F73.4070801@colorstudy.com> References: <5.1.1.6.0.20041129101329.02100bd0@mail.telecommunity.com> <6654eac4041125151452b0d216@mail.gmail.com> <6654eac404112509385ce97e44@mail.gmail.com> <5.1.1.6.0.20041125125555.02756410@mail.telecommunity.com> <6654eac4041125135746e8e0a8@mail.gmail.com> <5.1.1.6.0.20041125172640.0286c5f0@mail.telecommunity.com> <6654eac4041125151452b0d216@mail.gmail.com> <5.1.1.6.0.20041129101329.02100bd0@mail.telecommunity.com> <5.1.1.6.0.20041129160054.037e1210@mail.telecommunity.com> <41AB9F73.4070801@colorstudy.com> Message-ID: <41AC366D.5020602@xhaus.com> [Alan Kennedy] >>> 3. Even if we did use ConfigParser, it still doesn't solve the lack >>> of encoding support. [Phillip J. Eby] >> True, but entirely manageable for any 8-bit encoding that doesn't >> require escaping for the characters (such as #, ; , [, =, ], :, and >> whitespace) that ConfigParser uses for syntax. IOW, the various >> Latin codings and UTF-8 are all fine. [Ian Bicking] > Well, it returns text as 8-bit strings, not as unicode strings. I > think Alan wants unicode. Well, not exactly. I have no problem with using 8-bit strings, as long as they can be in encodings other than ascii or iso-8859-1. If we can support UTF-8, then the only problem for Indian, Korean, Chinese, Greek, Russian, etc, WSGI users is that their configuration files use more bytes than they would in a local encoding: they can still specify the full range of unicode characters using UTF-8. [Ian Bicking] >> I imagine it would be easy enough to add -- maybe >> enough just to open the file with an encoding specified (though being >> able to detect the encoding would be better). >> Or, if applied as a wrapper, you could decode all the strings after >> they've been loaded. Maybe that's what you were thinking? [Phillip J. Eby] > Yes, I meant decode-after-load, specifying the encoding as one of the > configuration variables. I'm a little confused. When you say "specifying the encoding as one of the configuration variables", do you mean a configuration variable that is specified inside or outside the ConfigParser .ini configuration file? Or somewhere else? Obviously, if you put the encoding declaration inside the config file itself, then you face the chicken and egg problem of needing to know what encoding the file is in before you can decode it to find out what its contents are, including what encoding it is in ....... XML solves this problem with the " -*-"). However, python is not able to use 2-byte encodings, for example UTF-16, because that would make the guessing algorithm too complex. From the PEP """ Any encoding which allows processing the first two lines in the way indicated above is allowed as source code encoding, this includes ASCII compatible encodings as well as certain multi-byte encodings such as Shift_JIS. It does not include encodings which use two or more bytes for all characters like e.g. UTF-16. The reason for this is to keep the encoding detection algorithm in the tokenizer simple. """ So if we're going to use ConfigParser *and* support encodings, then we need to either A: Make the user specify the encoding *outside* the configuration file B: Require some form of "magic string" at the top of the file so that we can guess the encoding. And write the guessing algorithm. Apart from encoding issues, I have no big problem with ConfigParser. My #1 choice is python syntax, but I understand that it may be overly complex for WSGI requirements. However, I do *not* like the java.util.Properties solution to the encoding problem: i.e. any character that isn't 8-bit must be specified with an Unicode escape. Which would mean that end-users would have to go looking up unicode hex/decimal character codes one by one. For non-technical users, this is unacceptable. Regards, Alan. From janssen at parc.com Tue Nov 30 17:02:05 2004 From: janssen at parc.com (Bill Janssen) Date: Tue Nov 30 17:02:31 2004 Subject: [Web-SIG] WSGI adoption In-Reply-To: Your message of "Tue, 30 Nov 2004 00:59:25 PST." <41AC366D.5020602@xhaus.com> Message-ID: <04Nov30.080206pst."58617"@synergy1.parc.xerox.com> > So if we're going to use ConfigParser *and* support encodings, then we > need to either > > A: Make the user specify the encoding *outside* the configuration file > B: Require some form of "magic string" at the top of the file so that we > can guess the encoding. And write the guessing algorithm. > > Apart from encoding issues, I have no big problem with ConfigParser. My > #1 choice is python syntax, but I understand that it may be overly > complex for WSGI requirements. There's the email approach, specified in RFC 2047. Bill From pje at telecommunity.com Tue Nov 30 17:00:49 2004 From: pje at telecommunity.com (Phillip J. Eby) Date: Tue Nov 30 17:02:37 2004 Subject: [Web-SIG] WSGI adoption In-Reply-To: <41AC366D.5020602@xhaus.com> References: <41AB9F73.4070801@colorstudy.com> <5.1.1.6.0.20041129101329.02100bd0@mail.telecommunity.com> <6654eac4041125151452b0d216@mail.gmail.com> <6654eac404112509385ce97e44@mail.gmail.com> <5.1.1.6.0.20041125125555.02756410@mail.telecommunity.com> <6654eac4041125135746e8e0a8@mail.gmail.com> <5.1.1.6.0.20041125172640.0286c5f0@mail.telecommunity.com> <6654eac4041125151452b0d216@mail.gmail.com> <5.1.1.6.0.20041129101329.02100bd0@mail.telecommunity.com> <5.1.1.6.0.20041129160054.037e1210@mail.telecommunity.com> <41AB9F73.4070801@colorstudy.com> Message-ID: <5.1.1.6.0.20041130103357.02101960@mail.telecommunity.com> At 08:59 AM 11/30/04 +0000, Alan Kennedy wrote: >[Phillip J. Eby] > > Yes, I meant decode-after-load, specifying the encoding as one of the > > configuration variables. > >I'm a little confused. When you say "specifying the encoding as one of the >configuration variables", do you mean a configuration variable that is >specified inside or outside the ConfigParser .ini configuration file? Or >somewhere else? > >Obviously, if you put the encoding declaration inside the config file >itself, then you face the chicken and egg problem of needing to know what >encoding the file is in before you can decode it to find out what its >contents are, including what encoding it is in ....... That was why I said it would only work for encodings that don't require escaping [, ], #, ;, =, and whitespace. >XML solves this problem with the "characters at the very beginning of the file from which you can guess the >character encoding of the file. More here > >http://www.w3.org/TR/REC-xml/#sec-guessing Reading this section makes it seem to me that we can easily support: """UTF-8, ISO 646, ASCII, some part of ISO 8859, Shift-JIS, EUC, or any other 7-bit, 8-bit, or mixed-width encoding which ensures that the characters of ASCII have their normal positions, width, and values """ ...as long as the configuration keys (and the string specifying the encoding) are guaranteed to be ASCII. It seems to me that most of the Asian codecs use unusual characters for escaping, such as $, \, and the ASCII escape character, so it shouldn't be too hard to steer clear of these in our keys. I would also recommend that application authors inform their users if their deployment files are in an encoding that is not bundled with Python. >So if we're going to use ConfigParser *and* support encodings, then we >need to either > >A: Make the user specify the encoding *outside* the configuration file >B: Require some form of "magic string" at the top of the file so that we >can guess the encoding. And write the guessing algorithm. As long as the encoding is restricted to basically the same set of encodings that work for Python source code, it should only be necessary to have the encoding specified as a configuration variable in the file. However, if it's considered desirable to also detect a BOM, we can implement that by reading the first four bytes of the file, and then either backing up if there's no BOM, or wrapping the file object with the appropriate decoding wrapper before passing it to ConfigParser. Of course, at that point we could just as well implement the exact same detection algorithm as PEP 263, except that we could also support wide encodings as long as there's a BOM. From py-web-sig at xhaus.com Tue Nov 30 19:00:48 2004 From: py-web-sig at xhaus.com (Alan Kennedy) Date: Tue Nov 30 19:02:24 2004 Subject: [Web-SIG] WSGI configuration and character encoding. In-Reply-To: <04Nov30.080206pst."58617"@synergy1.parc.xerox.com> References: <04Nov30.080206pst."58617"@synergy1.parc.xerox.com> Message-ID: <41ACB550.1080401@xhaus.com> [Alan Kennedy] >> Apart from encoding issues, I have no big problem with ConfigParser. >> My #1 choice is python syntax, but I understand that it may be overly >> complex for WSGI requirements. [Bill Janssen] > There's the email approach, specified in RFC 2047. I think that would be unworkable. Remember, we're talking about simple text files which would be edited using text editors like vi, Windows NotePad, etc. Such programs don't support encoding portions of a file, in RFC 2047 or otherwise. I don't think I could honestly expect non-technical users to be able to get their head around RFC 2047. For example, imagine that I wanted to use the Gaelic spelling of my name (al?in ? cinn?ide) as an email address @ python.org, to specify as the webmaster in a WSGI config file. The declaration would look like this webmaster: =?iso-8859-1?q?al=A0in=A2cinn=82ide=40python=2Eorg?= :-0~ Also, the RFC 2047 support (i.e. mimetools) is broken before python 2.2, when the email module was introduced. I think we need to focus on solutions that can be edited with something as basic as Windows Notepad. Regards, Alan. From py-web-sig at xhaus.com Tue Nov 30 19:03:30 2004 From: py-web-sig at xhaus.com (Alan Kennedy) Date: Tue Nov 30 19:05:16 2004 Subject: [Web-SIG] WSGI configuration and character encoding. In-Reply-To: <5.1.1.6.0.20041130103357.02101960@mail.telecommunity.com> References: <41AB9F73.4070801@colorstudy.com> <5.1.1.6.0.20041129101329.02100bd0@mail.telecommunity.com> <6654eac4041125151452b0d216@mail.gmail.com> <6654eac404112509385ce97e44@mail.gmail.com> <5.1.1.6.0.20041125125555.02756410@mail.telecommunity.com> <6654eac4041125135746e8e0a8@mail.gmail.com> <5.1.1.6.0.20041125172640.0286c5f0@mail.telecommunity.com> <6654eac4041125151452b0d216@mail.gmail.com> <5.1.1.6.0.20041129101329.02100bd0@mail.telecommunity.com> <5.1.1.6.0.20041129160054.037e1210@mail.telecommunity.com> <41AB9F73.4070801@colorstudy.com> <5.1.1.6.0.20041130103357.02101960@mail.telecommunity.com> Message-ID: <41ACB5F2.50600@xhaus.com> [Alan Kennedy] >> So if we're going to use ConfigParser *and* support encodings, then >> we need to either >> >> A: Make the user specify the encoding *outside* the configuration >> file >> B: Require some form of "magic string" at the top of the file so that >> we can guess the encoding. And write the guessing algorithm. [Phillip J. Eby] > As long as the encoding is restricted to basically the same set of > encodings that work for Python source code, it should only be > necessary to have the encoding specified as a configuration variable > in the file. > > However, if it's considered desirable to also detect a BOM, we can > implement that by reading the first four bytes of the file, and then > either backing up if there's no BOM, or wrapping the file object with > the appropriate decoding wrapper before passing it to ConfigParser. > > Of course, at that point we could just as well implement the exact > same detection algorithm as PEP 263, except that we could also support > wide encodings as long as there's a BOM. I'm really, really, really, really, *really* against us trying to come up with our own solution to the encoding problem. There are just too many pitfalls and special cases. Take XML 1.1, for example. XML 1.0 omitted the use of the IBM EBCDIC NEL character 0x85 as a permitted line terminator. XML 1.1 tried to rectify that omission, and despite the fact that dozens of clever people (i.e. the W3C XML working group) worked on the problem, and the spec was reviewed by literally thousands of eyeballs worldwide, they *all* *still* got it wrong! XML 1.1: Dead on Arrival http://norman.walsh.name/2004/09/30/xml11 I strongly urge that we adopt a solution that already has built-in encoding support, e.g. python or XML. Failing that, if we want to use ConfigParser, I see three ways forward 1. Make the user specify the encoding of the config file *outside* the config file itself. 2. Approach ein den deutsche-enkoding-bots on python-dev, e.g. MAL or MvL, and ask their advice. 3. Spend days or weeks bending our brains about how to make ConfigParser also do encodings, and about whether the proposed approach works or not. And what about WSGI implementors? I shudder to think what a poorly chosen solution could do to them. Just my ?0,02. Lastly, here's a wild suggestion: How about a hybrid approach? We use ConfigParser and the nice .ini syntax, but we wrap it in a simple XML wrapper, just so that we don't have to worry about encodings. For example #----begin---- [server] webmaster: al?in_?_cinn?ide@spam.org #-----end----- Ugly, but perfectly functional and trivial to implement too. Regards, Alan. From foom at fuhm.net Tue Nov 30 19:24:05 2004 From: foom at fuhm.net (James Y Knight) Date: Tue Nov 30 19:24:08 2004 Subject: [Web-SIG] WSGI configuration and character encoding. In-Reply-To: <41ACB5F2.50600@xhaus.com> References: <41AB9F73.4070801@colorstudy.com> <5.1.1.6.0.20041129101329.02100bd0@mail.telecommunity.com> <6654eac4041125151452b0d216@mail.gmail.com> <6654eac404112509385ce97e44@mail.gmail.com> <5.1.1.6.0.20041125125555.02756410@mail.telecommunity.com> <6654eac4041125135746e8e0a8@mail.gmail.com> <5.1.1.6.0.20041125172640.0286c5f0@mail.telecommunity.com> <6654eac4041125151452b0d216@mail.gmail.com> <5.1.1.6.0.20041129101329.02100bd0@mail.telecommunity.com> <5.1.1.6.0.20041129160054.037e1210@mail.telecommunity.com> <41AB9F73.4070801@colorstudy.com> <5.1.1.6.0.20041130103357.02101960@mail.telecommunity.com> <41ACB5F2.50600@xhaus.com> Message-ID: <0473C844-42FD-11D9-A0E4-000A95A50FB2@fuhm.net> On Nov 30, 2004, at 1:03 PM, Alan Kennedy wrote: > Failing that, if we want to use ConfigParser, I see three ways forward > > 1. Make the user specify the encoding of the config file *outside* the > config file itself. > 2. Approach ein den deutsche-enkoding-bots on python-dev, e.g. MAL or > MvL, and ask their advice. > 3. Spend days or weeks bending our brains about how to make > ConfigParser also do encodings, and about whether the proposed > approach works or not. And what about WSGI implementors? I shudder to > think what a poorly chosen solution could do to them. 4. Declare that the encoding is simply always UTF-8. James From pje at telecommunity.com Tue Nov 30 19:35:32 2004 From: pje at telecommunity.com (Phillip J. Eby) Date: Tue Nov 30 19:37:31 2004 Subject: [Web-SIG] WSGI configuration and character encoding. In-Reply-To: <41ACB5F2.50600@xhaus.com> References: <5.1.1.6.0.20041130103357.02101960@mail.telecommunity.com> <41AB9F73.4070801@colorstudy.com> <5.1.1.6.0.20041129101329.02100bd0@mail.telecommunity.com> <6654eac4041125151452b0d216@mail.gmail.com> <6654eac404112509385ce97e44@mail.gmail.com> <5.1.1.6.0.20041125125555.02756410@mail.telecommunity.com> <6654eac4041125135746e8e0a8@mail.gmail.com> <5.1.1.6.0.20041125172640.0286c5f0@mail.telecommunity.com> <6654eac4041125151452b0d216@mail.gmail.com> <5.1.1.6.0.20041129101329.02100bd0@mail.telecommunity.com> <5.1.1.6.0.20041129160054.037e1210@mail.telecommunity.com> <41AB9F73.4070801@colorstudy.com> <5.1.1.6.0.20041130103357.02101960@mail.telecommunity.com> Message-ID: <5.1.1.6.0.20041130132555.02ceebc0@mail.telecommunity.com> At 06:03 PM 11/30/04 +0000, Alan Kennedy wrote: >[Phillip J. Eby] > > As long as the encoding is restricted to basically the same set of > > encodings that work for Python source code, it should only be > > necessary to have the encoding specified as a configuration variable > > in the file. > > > > However, if it's considered desirable to also detect a BOM, we can > > implement that by reading the first four bytes of the file, and then > > either backing up if there's no BOM, or wrapping the file object with > > the appropriate decoding wrapper before passing it to ConfigParser. > > > > Of course, at that point we could just as well implement the exact > > same detection algorithm as PEP 263, except that we could also support > > wide encodings as long as there's a BOM. > >I'm really, really, really, really, *really* against us trying to come up >with our own solution to the encoding problem. There are just too many >pitfalls and special cases. You've lost me here. I was suggesting that we use PEP 263 or a subset thereof. I've seen the patches for PEP 263, and they're pretty darn simple, even in C! >Take XML 1.1, for example. XML 1.0 omitted the use of the IBM EBCDIC NEL >character 0x85 as a permitted line terminator. XML 1.1 tried to rectify >that omission, and despite the fact that dozens of clever people (i.e. the >W3C XML working group) worked on the problem, and the spec was reviewed by >literally thousands of eyeballs worldwide, they *all* *still* got it wrong! > >XML 1.1: Dead on Arrival >http://norman.walsh.name/2004/09/30/xml11 > >I strongly urge that we adopt a solution that already has built-in >encoding support, e.g. python or XML. If by "solution" you mean "implementation", it doesn't really solve anything in the XML case, because for example a specific XML library could be completely broken with respect to Unicode... and many of them are! If by "solution" you mean "detection algorithm", then I'm fine with that; the PEP 263 algorithm can be easily coded in Python as a front-end to ConfigParser. >Failing that, if we want to use ConfigParser, I see three ways forward > >1. Make the user specify the encoding of the config file *outside* the >config file itself. I think that will lead to significant complications for simple servers (e.g. ones that just want to publish files in a directory) >2. Approach ein den deutsche-enkoding-bots on python-dev, e.g. MAL or MvL, >and ask their advice. Sure, although I also assume that their input has already gone into PEP 263, so using it as-is should be fine. >3. Spend days or weeks bending our brains about how to make ConfigParser >also do encodings, and about whether the proposed approach works or not. What's wrong with PEP 263? >Lastly, here's a wild suggestion: How about a hybrid approach? We use >ConfigParser and the nice .ini syntax, but we wrap it in a simple XML >wrapper, just so that we don't have to worry about encodings. For example > >#----begin---- > > > >[server] >webmaster: al?in_?_cinn?ide@spam.org > > >#-----end----- > >Ugly, but perfectly functional and trivial to implement too. And it introduces all the problems of < > & ", too. It'd be simpler to just use: # encoding:windows-1252 [server] webmaster: al?in_?_cinn?ide@spam.org Which is one of several valid ways to spell an encoding declaration under PEP 263, that is also a valid comment in ConfigParser .ini format. From pje at telecommunity.com Tue Nov 30 19:47:00 2004 From: pje at telecommunity.com (Phillip J. Eby) Date: Tue Nov 30 19:48:58 2004 Subject: [Web-SIG] WSGI configuration and character encoding. In-Reply-To: <5.1.1.6.0.20041130132555.02ceebc0@mail.telecommunity.com> References: <41ACB5F2.50600@xhaus.com> <5.1.1.6.0.20041130103357.02101960@mail.telecommunity.com> <41AB9F73.4070801@colorstudy.com> <5.1.1.6.0.20041129101329.02100bd0@mail.telecommunity.com> <6654eac4041125151452b0d216@mail.gmail.com> <6654eac404112509385ce97e44@mail.gmail.com> <5.1.1.6.0.20041125125555.02756410@mail.telecommunity.com> <6654eac4041125135746e8e0a8@mail.gmail.com> <5.1.1.6.0.20041125172640.0286c5f0@mail.telecommunity.com> <6654eac4041125151452b0d216@mail.gmail.com> <5.1.1.6.0.20041129101329.02100bd0@mail.telecommunity.com> <5.1.1.6.0.20041129160054.037e1210@mail.telecommunity.com> <41AB9F73.4070801@colorstudy.com> <5.1.1.6.0.20041130103357.02101960@mail.telecommunity.com> Message-ID: <5.1.1.6.0.20041130133636.02ced9e0@mail.telecommunity.com> At 01:35 PM 11/30/04 -0500, Phillip J. Eby wrote: >It'd be simpler to just use: > ># encoding:windows-1252 >[server] >webmaster: al?in_?_cinn?ide@spam.org > >Which is one of several valid ways to spell an encoding declaration under >PEP 263, that is also a valid comment in ConfigParser .ini format. Also note that *this*: [wsgi] encoding=windows-1252 Is a valid encoding prefix under PEP 263, which is why I was suggesting that simply embedding an encoding option could be sufficient. However, given the reasonable use case of BOM-prefixed files, I think it would be best to use the PEP 263 specification instead, perhaps with the addition of support for 16 or 32 bit encodings so long as they are indicated by a BOM at the beginning of the file. From titus at caltech.edu Tue Nov 30 20:01:54 2004 From: titus at caltech.edu (Titus Brown) Date: Tue Nov 30 20:01:58 2004 Subject: [Web-SIG] WSGI Utils & SCGI/Quixote. Message-ID: <20041130190154.GA12058@caltech.edu> Hi, Colin et al., I tried out my Quixote (application) and SCGI (server) adapters with your wsgiUtils package this morning. With a few tweaks, everything worked; hooray! Thanks for making wsgiutils available; it's nice to know that my code actually works with someone else's ;). The SCGI server adapter ("SWAP") worked out of the box with both of your app objects, e.g. --- class TestAppHandler(swap.SWAP): def __init__(self, *args, **kwargs): print 'creating new TestAppHandler' self.prefix = '/canal' # just my setup... ### hook into wsgiUtils adaptor = wsgiAdaptor.wsgiAdaptor (CalcApp(), 'siteCookieKey', calcclient) self.app_obj = adaptor.wsgiHook ### swap.SWAP.__init__(self, *args, **kwargs) if __name__ == '__main__': scgi_server.SCGIServer(TestAppHandler, port=4000).serve() --- The Quixote app adapter ("QWIP") took a little more time, but it now works like so: --- demo_obj = qwip.QWIP('quixote.demo') server = wsgiServer.WSGIServer (('issola.caltech.edu', 1088), {'/demo': demo_obj}) server.serve_forever() --- The only real problem in getting this to work was that wsgiServer.py expected *every* URL under /demo to be registered to demo_obj. I changed the wsgiServer.py code to allow for partial matches & munged the SCRIPT_NAME and PATH_INFO variables appropriately. I also added REQUEST_URI because Quixote uses it for a few things; this should probably be moved into QWIP. A context-diff of my changes to wsgiServer.py is attached, for your enjoyment ;). My experience highlights an issue that needs to be dealt with by any WSGI server code. Several app frameworks -- Quixote Webware, and Zope, for example -- expect to be handed control of an entire URL tree. Moreover this needs to be signalled appropriately via SCRIPT_NAME and PATH_INFO. Colin, I'd be happy to test whatever system you come up with... although the quixote.demo code (attached) should work with a simple Quixote install. cheers, --titus p.s. http://issola.caltech.edu/~t/transfer/qwsgi/README.html http://issola.caltech.edu/~t/transfer/qwip-and-swap-26.11.04.tar.gz p.p.s. full test scripts + full modified wsgiServer.py attached. -------------- next part -------------- *** wsgiServer.py 2004-11-30 10:52:38.000000000 -0800 --- ../WSGI Utils-0.2/lib/wsgiutils/wsgiServer.py 2004-11-03 19:44:10.000000000 -0800 *************** *** 33,51 **** import SimpleHTTPServer, SocketServer, BaseHTTPServer, urlparse import sys, logging - def get_wsgi_app(app_dict, path): - if app_dict.has_key(path): # exact match - return (path, app_dict[path]) - - keys = app_dict.keys() - keys.sort() - keys.reverse() # so that /url/suburl is before /url - for url in keys: - if path.find(url) == 0: - return (url, app_dict[url]) - - return (None, None) - class WSGIHandler (SimpleHTTPServer.SimpleHTTPRequestHandler): def log_message (self, *args): pass --- 33,38 ---- *************** *** 56,90 **** def do_GET (self): protocol, host, path, parameters, query, fragment = urlparse.urlparse ('http://dummyhost%s' % self.path) logging.info ("Received GET for path %s" % path) ! ! (app_path, app) = get_wsgi_app(self.server.wsgiApplications, path) ! ! if (not app): # Not a request for an application, just a file. SimpleHTTPServer.SimpleHTTPRequestHandler.do_GET (self) return ! ! self.runWSGIApp (app, app_path, path, query) def do_POST (self): protocol, host, path, parameters, query, fragment = urlparse.urlparse ('http://dummyhost%s' % self.path) logging.info ("Received POST for path %s" % path) ! ! (app_path, app) = get_wsgi_app(self.server.wsgiApplications, path) ! ! if (not app): # We don't have an application corresponding to this path! self.send_error (404, 'Application not found.') return ! self.runWSGIApp (app, app_path, path, query) ! ! def runWSGIApp (self, application, path_head, full_path, query): ! logging.info ("Running application for path %s" % full_path) ! ! # pick off that which matches the app path head. ! path_tail = full_path[len(path_head):] ! env = {'wsgi.version': (1,0) ,'wsgi.url_scheme': 'http' ,'wsgi.input': self.rfile --- 43,65 ---- def do_GET (self): protocol, host, path, parameters, query, fragment = urlparse.urlparse ('http://dummyhost%s' % self.path) logging.info ("Received GET for path %s" % path) ! if (not self.server.wsgiApplications.has_key (path)): # Not a request for an application, just a file. SimpleHTTPServer.SimpleHTTPRequestHandler.do_GET (self) return ! self.runWSGIApp (self.server.wsgiApplications [path], path, query) def do_POST (self): protocol, host, path, parameters, query, fragment = urlparse.urlparse ('http://dummyhost%s' % self.path) logging.info ("Received POST for path %s" % path) ! if (not self.server.wsgiApplications.has_key (path)): # We don't have an application corresponding to this path! self.send_error (404, 'Application not found.') return + self.runWSGIApp (self.server.wsgiApplications [path], path, query) ! def runWSGIApp (self, application, path, query): ! logging.info ("Running application for path %s" % path) env = {'wsgi.version': (1,0) ,'wsgi.url_scheme': 'http' ,'wsgi.input': self.rfile *************** *** 93,101 **** ,'wsgi.multiprocess': 0 ,'wsgi.run_once': 0 ,'REQUEST_METHOD': self.command ! ,'SCRIPT_NAME': path_head ! ,'PATH_INFO': path_tail ! ,'REQUEST_URI' : full_path ,'QUERY_STRING': query ,'CONTENT_TYPE': self.headers.get ('Content-Type', '') ,'CONTENT_LENGTH': self.headers.get ('Content-Length', '') --- 68,75 ---- ,'wsgi.multiprocess': 0 ,'wsgi.run_once': 0 ,'REQUEST_METHOD': self.command ! ,'SCRIPT_NAME': path ! ,'PATH_INFO': '' ,'QUERY_STRING': query ,'CONTENT_TYPE': self.headers.get ('Content-Type', '') ,'CONTENT_LENGTH': self.headers.get ('Content-Length', '') -------------- next part -------------- #! /usr/bin/env python2.3 import sys sys.path.insert(0, "/u/t/dev/qwsgi/") from wsgiutils import wsgiServer import qwip demo_obj = qwip.QWIP('quixote.demo') server = wsgiServer.WSGIServer (('issola.caltech.edu', 1088), {'/demo': demo_obj}) server.serve_forever() -------------- next part -------------- #!/usr/bin/env python2.3 from wsgiutils import SessionClient, wsgiAdaptor import sys import time import os import getopt from scgi import scgi_server import swap class TestApp: def requestHandler (self, request): # This is a multi-threaded area, we must be thread safe. request.setContentType ('text/html') session = request.getSession() if (session.has_key ('lastRequestTime')): lastRequest = session ['lastRequestTime'] else: lastRequest = None thisTime = time.time() session ['lastRequestTime'] = thisTime # Use some templating library to generate some output if (lastRequest is None): return "

The first request!

" else: return "

The time is %s, last request was at %s

" % (str (thisTime), str (lastRequest)) class CalcApp: """ A simple calculator app that uses a username/password of 'user/user' and demonstrates forms. """ def requestHandler (self, request): request.setContentType ('text/html') # Authenticate the user username = request.getUsername() password = request.getPassword() if (username is None or username != 'user'): request.unauthorisedBasic ("Calculator") return "" if (password is None or password != 'user'): request.unauthorisedBasic ("Calculator") return "" # We have a valid user, so get the form entries formData = request.getFormFields() try: firstValue = float (formData.getfirst ('value1', "0")) secondValue = float (formData.getfirst ('value2', "0")) except: # No valid numbers, try again return self.displayForm(request, 0) # Display the sum return self.displayForm (request, firstValue + secondValue) def displayForm (self, request, sumValue): return """

Calculator

Last answer was: %s


""" % str (sumValue) testclient = SessionClient.LocalSessionClient('session.dbm', 'testappid') testadaptor = wsgiAdaptor.wsgiAdaptor (TestApp(), 'siteCookieKey', testclient) calcclient = SessionClient.LocalSessionClient ('calcsession.dbm', 'calcid') calcAdaptor = wsgiAdaptor.wsgiAdaptor (CalcApp(), 'siteCookieKey', calcclient) class TestAppHandler(swap.SWAP): def __init__(self, *args, **kwargs): print 'creating new TestAppHandler' self.prefix = '/canal' # just my setup... self.app_obj = wsgiAdaptor.wsgiAdaptor (CalcApp(), 'siteCookieKey', calcclient).wsgiHook swap.SWAP.__init__(self, *args, **kwargs) if __name__ == '__main__': scgi_server.SCGIServer(TestAppHandler, port=4000).serve() -------------- next part -------------- """ wsgiServer Copyright (c) 2004 Colin Stewart (http://www.owlfish.com/) All rights reserved. Redistribution and use in source and binary forms, with or without modification, are permitted provided that the following conditions are met: 1. Redistributions of source code must retain the above copyright notice, this list of conditions and the following disclaimer. 2. Redistributions in binary form must reproduce the above copyright notice, this list of conditions and the following disclaimer in the documentation and/or other materials provided with the distribution. 3. The name of the author may not be used to endorse or promote products derived from this software without specific prior written permission. THIS SOFTWARE IS PROVIDED BY THE AUTHOR ``AS IS'' AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. If you make any bug fixes or feature enhancements please let me know! A basic multi-threaded WSGI server. """ import SimpleHTTPServer, SocketServer, BaseHTTPServer, urlparse import sys, logging def get_wsgi_app(app_dict, path): if app_dict.has_key(path): # exact match return (path, app_dict[path]) keys = app_dict.keys() keys.sort() keys.reverse() # so that /url/suburl is before /url for url in keys: if path.find(url) == 0: return (url, app_dict[url]) return (None, None) class WSGIHandler (SimpleHTTPServer.SimpleHTTPRequestHandler): def log_message (self, *args): pass def log_request (self, *args): pass def do_GET (self): protocol, host, path, parameters, query, fragment = urlparse.urlparse ('http://dummyhost%s' % self.path) logging.info ("Received GET for path %s" % path) (app_path, app) = get_wsgi_app(self.server.wsgiApplications, path) if (not app): # Not a request for an application, just a file. SimpleHTTPServer.SimpleHTTPRequestHandler.do_GET (self) return self.runWSGIApp (app, app_path, path, query) def do_POST (self): protocol, host, path, parameters, query, fragment = urlparse.urlparse ('http://dummyhost%s' % self.path) logging.info ("Received POST for path %s" % path) (app_path, app) = get_wsgi_app(self.server.wsgiApplications, path) if (not app): # We don't have an application corresponding to this path! self.send_error (404, 'Application not found.') return self.runWSGIApp (app, app_path, path, query) def runWSGIApp (self, application, path_head, full_path, query): logging.info ("Running application for path %s" % full_path) # pick off that which matches the app path head. path_tail = full_path[len(path_head):] env = {'wsgi.version': (1,0) ,'wsgi.url_scheme': 'http' ,'wsgi.input': self.rfile ,'wsgi.errors': sys.stderr ,'wsgi.multithread': 1 ,'wsgi.multiprocess': 0 ,'wsgi.run_once': 0 ,'REQUEST_METHOD': self.command ,'SCRIPT_NAME': path_head ,'PATH_INFO': path_tail ,'REQUEST_URI' : full_path ,'QUERY_STRING': query ,'CONTENT_TYPE': self.headers.get ('Content-Type', '') ,'CONTENT_LENGTH': self.headers.get ('Content-Length', '') ,'REMOTE_ADDR': self.client_address[0] ,'SERVER_NAME': self.server.server_address [0] ,'SERVER_PORT': self.server.server_address [1] ,'SERVER_PROTOCOL': self.request_version } for httpHeader, httpValue in self.headers.items(): env ['HTTP_%s' % httpHeader.replace ('-', '_').upper()] = httpValue # Setup the state self.wsgiSentHeaders = 0 self.wsgiHeaders = [] # We have the environment, now invoke the application result = application (env, self.wsgiStartResponse) for data in result: if data: self.wsgiWriteData (data) if (not self.wsgiSentHeaders): # We must write out something! self.wsgiWriteData ("") return def wsgiStartResponse (self, response_status, response_headers, exc_info=None): if (self.wsgiSentHeaders): raise Exception ("Headers already sent and start_response called again!") # Should really take a copy to avoid changes in the application.... self.wsgiHeaders = (response_status, response_headers) return self.wsgiWriteData def wsgiWriteData (self, data): if (not self.wsgiSentHeaders): status, headers = self.wsgiHeaders # Need to send header prior to data statusCode = status [:status.find (' ')] statusMsg = status [status.find (' ') + 1:] self.send_response (int (statusCode), statusMsg) for header, value in headers: self.send_header (header, value) self.end_headers() self.wsgiSentHeaders = 1 # Send the data self.wfile.write (data) class WSGIServer (SocketServer.ThreadingMixIn, BaseHTTPServer.HTTPServer): def __init__ (self, serverAddress, wsgiApplications): BaseHTTPServer.HTTPServer.__init__ (self, serverAddress, WSGIHandler) self.wsgiApplications = wsgiApplications self.serverShuttingDown = 0 From py-web-sig at xhaus.com Tue Nov 30 20:27:50 2004 From: py-web-sig at xhaus.com (Alan Kennedy) Date: Tue Nov 30 20:31:19 2004 Subject: [Web-SIG] WSGI configuration and character encoding. In-Reply-To: <5.1.1.6.0.20041130132555.02ceebc0@mail.telecommunity.com> References: <5.1.1.6.0.20041130103357.02101960@mail.telecommunity.com> <41AB9F73.4070801@colorstudy.com> <5.1.1.6.0.20041129101329.02100bd0@mail.telecommunity.com> <6654eac4041125151452b0d216@mail.gmail.com> <6654eac404112509385ce97e44@mail.gmail.com> <5.1.1.6.0.20041125125555.02756410@mail.telecommunity.com> <6654eac4041125135746e8e0a8@mail.gmail.com> <5.1.1.6.0.20041125172640.0286c5f0@mail.telecommunity.com> <6654eac4041125151452b0d216@mail.gmail.com> <5.1.1.6.0.20041129101329.02100bd0@mail.telecommunity.com> <5.1.1.6.0.20041129160054.037e1210@mail.telecommunity.com> <41AB9F73.4070801@colorstudy.com> <5.1.1.6.0.20041130103357.02101960@mail.telecommunity.com> <5.1.1.6.0.20041130132555.02ceebc0@mail.telecommunity.com> Message-ID: <41ACC9B6.7080402@xhaus.com> [Alan Kennedy] >> I'm really, really, really, really, *really* against us trying to >> come up with our own solution to the encoding problem. There are just >> too many pitfalls and special cases. [Phillip J. Eby] > You've lost me here. I was suggesting that we use PEP 263 or a subset > thereof. I've seen the patches for PEP 263, and they're pretty darn > simple, even in C! Sorry, I've obviously misunderstood. I thought you were talking about devising a new encoding solution/mechanism/implementation. I didn't realise that you were proposing actually using the algorithm/implementation from PEP-263. Partly, this would have been because I thought (mistakenly?) that the PEP-263 implementation was not available from pure python code? CF this recent thread on python-list. PEP263 + exec statement http://mail.python.org/pipermail/python-list/2004-November/252330.html But even if implementors have to code the algorithm themselves, (short enough to present in PEP-333?), I'm +0.5 on that if the implementation is as simple/straightforward as Phillip says it is (even in c ;-) But my unreserved support is reserved for [James Y Knight] > 4. Declare that the encoding is simply always UTF-8. +1! I'd also be happy with # encoding:windows-1252 [server] webmaster: al?in_?_cinn?ide@spam.org That looks simple and works well. Lastly, I had forgotten that [Alan's wild and ugly proposal to address the encoding problem .. snipped] > .. introduces all the problems of < > & ", too. I do find < & " & ' & > particularly annoying when writing python, javascript or even xpath inside xslt files. Regards, Alan. From pje at telecommunity.com Tue Nov 30 20:44:42 2004 From: pje at telecommunity.com (Phillip J. Eby) Date: Tue Nov 30 20:46:48 2004 Subject: [Web-SIG] WSGI Utils & SCGI/Quixote. In-Reply-To: <20041130190154.GA12058@caltech.edu> Message-ID: <5.1.1.6.0.20041130142125.02101070@mail.telecommunity.com> At 11:01 AM 11/30/04 -0800, Titus Brown wrote: >The only real problem in getting this to work was that wsgiServer.py >expected *every* URL under /demo to be registered to demo_obj. I >changed the wsgiServer.py code to allow for partial matches & munged >the SCRIPT_NAME and PATH_INFO variables appropriately. I also added >REQUEST_URI because Quixote uses it for a few things; this should >probably be moved into QWIP. I think I'm going to have to call that point out in the PEP somewhere. Technically, the PEP requires that SCRIPT_NAME and PATH_INFO be set, but I think perhaps some folks have missed the implications of that for the URL path space. Perhaps something like this would do the trick: """ Application Placement in Server URL Space ----------------------------------------- In order to generate correct SCRIPT_NAME and PATH_INFO variables, servers and gateways MUST treat an application's location as a URL path prefix. That is, servers and gateways: * MUST determine the target application using a matching prefix of the request path (which then determines the value of SCRIPT_NAME). * MUST take the remaining portion of the request path, and use it to determine PATH_INFO. (Note that the remainder must be empty or begin with a '/', otherwise the prefix match was invalid!) * MUST assume that there are an infinite number of possible URL paths that may appear as a PATH_INFO suffix "beneath" the application's base URL Notice that these requirements imply that servers and gateways: * MUST NOT use query string contents, fragment identifiers, or URL parameters to determine the application object that a request should be sent to. * MUST NOT require that every URL path used by the application be preconfigured or pre-registered with the server, or have some required mapping to existing files, or any other requirement that would make dynamic URLs impractical. A server or gateway that cannot meet these requirements IS NOT COMPLIANT with this specification; it would be completely unusable for applications from many popular Python web frameworks inlcuding at least Zope, Webware, and Quixote, and many standalone Python web applications as well. """ From janssen at parc.com Tue Nov 30 21:10:05 2004 From: janssen at parc.com (Bill Janssen) Date: Tue Nov 30 21:10:26 2004 Subject: [Web-SIG] WSGI configuration and character encoding. In-Reply-To: Your message of "Tue, 30 Nov 2004 10:00:48 PST." <41ACB550.1080401@xhaus.com> Message-ID: <04Nov30.121007pst."58617"@synergy1.parc.xerox.com> > I don't think I could honestly expect non-technical users to be able to > get their head around RFC 2047. I wouldn't be expecting non-technical users to be editing WSGI config files in the first place. Bill From fumanchu at amor.org Tue Nov 30 21:11:29 2004 From: fumanchu at amor.org (Robert Brewer) Date: Tue Nov 30 21:13:22 2004 Subject: [Web-SIG] WSGI configuration and character encoding. Message-ID: <3A81C87DC164034AA4E2DDFE11D258E32452DC@exchange.hqamor.amorhq.net> Bill Janssen wrote: > > I don't think I could honestly expect non-technical users > to be able to > > get their head around RFC 2047. > > I wouldn't be expecting non-technical users to be editing WSGI config > files in the first place. *boggle* I certainly would. "Plug and play" is still the holy grail of framework developers. If WSGI makes mine *more* difficult to deploy than it already is, it becomes much less attractive. Robert Brewer MIS Amor Ministries fumanchu@amor.org From pje at telecommunity.com Tue Nov 30 23:07:53 2004 From: pje at telecommunity.com (Phillip J. Eby) Date: Tue Nov 30 23:10:05 2004 Subject: [Web-SIG] WSGI configuration and character encoding. In-Reply-To: <04Nov30.121007pst."58617"@synergy1.parc.xerox.com> References: Message-ID: <5.1.1.6.0.20041130170653.038ef0d0@mail.telecommunity.com> At 12:10 PM 11/30/04 -0800, Bill Janssen wrote: > > I don't think I could honestly expect non-technical users to be able to > > get their head around RFC 2047. > >I wouldn't be expecting non-technical users to be editing WSGI config >files in the first place. That's one of our explicit requirements, actually. We don't need them to be able to *create* a deployment file, but they should be able to edit one to tweak file paths and such. From titus at caltech.edu Tue Nov 30 23:21:46 2004 From: titus at caltech.edu (Titus Brown) Date: Tue Nov 30 23:22:43 2004 Subject: [Web-SIG] Quixote/SCGI adapters for WSGI -- Web site. Message-ID: <20041130222146.GB1371@caltech.edu> Hi all, I've just dumped my WSGI adapters for Quixote/SCGI on a page at http://www.idyll.org/~t/www-tools/wsgi/ if someone could add this to the WSGIImplementations Wiki, I'd appreciate it... The new README contains more information on how to *use* the darn things, and the updated distro contains the wsgiUtils scripts I posted before as well as a fix to QWIP (the Quixote adapter) to munge REQUEST_URI together if it doesn't already exist. I'll post about any significant changes if they happen. cheers, --titus From pje at telecommunity.com Tue Nov 30 23:26:37 2004 From: pje at telecommunity.com (Phillip J. Eby) Date: Tue Nov 30 23:28:53 2004 Subject: [Web-SIG] Quixote/SCGI adapters for WSGI -- Web site. In-Reply-To: <20041130222146.GB1371@caltech.edu> Message-ID: <5.1.1.6.0.20041130172555.025f1de0@mail.telecommunity.com> At 02:21 PM 11/30/04 -0800, Titus Brown wrote: >Hi all, > >I've just dumped my WSGI adapters for Quixote/SCGI on a page at > > http://www.idyll.org/~t/www-tools/wsgi/ > >if someone could add this to the WSGIImplementations Wiki, I'd >appreciate it... FYI, you can edit the page yourself, you just have to sign in. Click on "UserPreferences" in the upper right of the page, then fill out the form.