Re: [Web-SIG] Standardized configuration

2005-07-23 Thread Ian Bicking
To do this, we use a ConfigParser-format config file named 'myapplication.conf' that looks like this:: [application:sample1] config = sample1.conf factory = wsgiconfig.tests.sample_components.factory1 [application:sample2] config = sample2.conf factory =

Re: [Web-SIG] Standardized configuration

2005-07-23 Thread Chris McDonough
On Fri, 2005-07-22 at 17:26 -0500, Ian Bicking wrote: To do this, we use a ConfigParser-format config file named 'myapplication.conf' that looks like this:: [application:sample1] config = sample1.conf factory = wsgiconfig.tests.sample_components.factory1

Re: [Web-SIG] Standardized configuration

2005-07-23 Thread Ian Bicking
Chris McDonough wrote: On Fri, 2005-07-22 at 17:26 -0500, Ian Bicking wrote: To do this, we use a ConfigParser-format config file named 'myapplication.conf' that looks like this:: [application:sample1] config = sample1.conf factory = wsgiconfig.tests.sample_components.factory1

Re: [Web-SIG] Standardized configuration

2005-07-23 Thread Phillip J. Eby
At 08:41 PM 7/23/2005 -0400, Chris McDonough wrote: On Sat, 2005-07-23 at 20:21 -0400, Phillip J. Eby wrote: At 08:08 PM 7/23/2005 -0400, Chris McDonough wrote: Would you maybe rather make it more explicit that some apps are also gateways, e.g.: [application:bleeb] config = bleeb.conf

Re: [Web-SIG] Standardized configuration

2005-07-22 Thread Chris McDonough
I've had a stab at creating a simple WSGI deployment implementation. I use the term WSGI component in here as shorthand to indicate all types of WSGI implementations (server, application, gateway). The primary deployment concern is to create a way to specify the configuration of an instance of a

Re: [Web-SIG] Standardized configuration

2005-07-19 Thread Chris McDonough
On Mon, 2005-07-18 at 22:49 -0500, Ian Bicking wrote: In addition to the examples I gave in response to Graham, I wrote a document on this a while ago: http://pythonpaste.org/docs/url-parsing-with-wsgi.html The hard part about this is configuration; it's easy to configure a non-branching

Re: [Web-SIG] Standardized configuration

2005-07-19 Thread Ian Bicking
Chris McDonough wrote: On Mon, 2005-07-18 at 22:49 -0500, Ian Bicking wrote: In addition to the examples I gave in response to Graham, I wrote a document on this a while ago: http://pythonpaste.org/docs/url-parsing-with-wsgi.html The hard part about this is configuration; it's easy to

Re: [Web-SIG] Standardized configuration

2005-07-19 Thread Ian Bicking
Phillip J. Eby wrote: In many cases, the middleware is modifying or watching the application's output. For instance, catching a 401 and turning that into the appropriate login -- which might mean producing a 401, a redirect, a login page via internal redirect, or whatever. And that

Re: [Web-SIG] Standardized configuration

2005-07-19 Thread mike bayer
While I'm not following every detail of this discussion, this line caught my attention - Ian Bicking said: Really, if you are building user-visible standard libraries, you are building a framework. only because Fowler recently posted something that made me think about this, where he

Re: [Web-SIG] Standardized configuration

2005-07-19 Thread ChunWei Ho
(b) Have chain application = authmiddleware(fileserverapp) Use Handlers, as Ian suggested, and in the fileserverapp's init: Handlers( IfTest(method=GET,MimeOkForGzip=True, RunApp=gzipmiddleware(doGET)), IfTest(method=GET,MimeOkForGzip=False, RunApp=doGET),

Re: [Web-SIG] Standardized configuration

2005-07-18 Thread Ian Bicking
Graham Dumpleton wrote: My understanding from reading the WSGI PEP and examples like that above is that the WSGI middleware stack concept is very much tree like, but where at any specific node within the tree, one can only traverse into one child. Ie., a parent middleware component could

Re: [Web-SIG] Standardized configuration

2005-07-17 Thread Ian Bicking
Chris McDonough wrote: Because middleware can't be introspected (generally), this makes things like configuration schemas very hard to implement. It all needs to be late-bound. The pipeline itself isn't really late bound. For instance, if I was to create a WSGI middleware pipeline

Re: [Web-SIG] Standardized configuration

2005-07-17 Thread Ian Bicking
Phillip J. Eby wrote: At 01:57 PM 7/11/2005 -0500, Ian Bicking wrote: Lately I've been thinking about the role of Paste and WSGI and whatnot. Much of what makes a Paste component Pastey is configuration; otherwise the bits are just independent pieces of middleware, WSGI applications, etc.

Re: [Web-SIG] Standardized configuration

2005-07-17 Thread Graham Dumpleton
On 17/07/2005, at 6:16 PM, Ian Bicking wrote: The pipeline itself isn't really late bound. For instance, if I was to create a WSGI middleware pipeline something like this: server -- session -- identification -- authentication -- -- challenge -- application ... session,

Re: [Web-SIG] Standardized configuration

2005-07-17 Thread Chris McDonough
On Sun, 2005-07-17 at 03:16 -0500, Ian Bicking wrote: This is what Paste does in configuration, like: middleware.extend([ SessionMiddleware, IdentificationMiddleware, AuthenticationMiddleware, ChallengeMiddleware]) This kind of middleware takes a single argument, which is the

Re: [Web-SIG] Standardized configuration

2005-07-17 Thread Phillip J. Eby
At 07:29 AM 7/17/2005 -0400, Chris McDonough wrote: I'm a bit confused because one of the canonical examples of how WSGI middleware is useful seems to be the example of implementing a framework-agnostic sessioning service. And for that sessioning service to be useful, your application has to be

Re: [Web-SIG] Standardized configuration

2005-07-17 Thread Phillip J. Eby
At 03:28 AM 7/17/2005 -0500, Ian Bicking wrote: Phillip J. Eby wrote: What I think you actually need is a way to create WSGI application objects with a context object. The context object would have a method like get_service(name), and if it didn't find the service, it would ask its parent

[Web-SIG] Standardized configuration

2005-07-16 Thread Chris McDonough
I've also been putting a bit of thought into middleware configuration, although maybe in a different direction. I'm not too concerned yet about being able to introspect the configuration of an individual component. Maybe that's because I haven't thought about the problem enough to be concerned

Re: [Web-SIG] Standardized configuration

2005-07-16 Thread Jp Calderone
http://twistedmatrix.com/pipermail/twisted-python/2005-July/010902.html might be of interest on this topic. Jp ___ Web-SIG mailing list Web-SIG@python.org Web SIG: http://www.python.org/sigs/web-sig Unsubscribe:

Re: [Web-SIG] Standardized configuration

2005-07-16 Thread Ian Bicking
Chris McDonough wrote: I've also been putting a bit of thought into middleware configuration, although maybe in a different direction. I'm not too concerned yet about being able to introspect the configuration of an individual component. Maybe that's because I haven't thought about the

Re: [Web-SIG] Standardized configuration

2005-07-16 Thread Phillip J. Eby
At 01:57 PM 7/11/2005 -0500, Ian Bicking wrote: Lately I've been thinking about the role of Paste and WSGI and whatnot. Much of what makes a Paste component Pastey is configuration; otherwise the bits are just independent pieces of middleware, WSGI applications, etc. So, potentially if we can

Re: [Web-SIG] Standardized configuration

2005-07-16 Thread Chris McDonough
On Sat, 2005-07-16 at 23:29 -0500, Ian Bicking wrote: There's nothing in WSGI to facilitate introspection. Sometimes that seems annoying, though I suspect lots of headaches are removed because of it, and I haven't found it to be a stopper yet. The issue I'm interested in is just how to

[Web-SIG] Standardized configuration

2005-07-11 Thread Ian Bicking
Lately I've been thinking about the role of Paste and WSGI and whatnot. Much of what makes a Paste component Pastey is configuration; otherwise the bits are just independent pieces of middleware, WSGI applications, etc. So, potentially if we can agree on configuration, we can start using