At 04:05 AM 7/24/2005 -0400, Chris McDonough wrote:
>- OR (if we passed the factory a namespace instead of a filename) -
>
> [foo.factory]
> arbitrarykey1 = arbitraryvalue1
> arbitrarykey2 = arbitraryvalue2
>
> [bar.factory]
> arbitrarykey1 = arbitraryvalue1
> arbitrarykey2 = arbitraryv
Thanks for the response... I'm not going to respond point-by-point here
because probably nobody has time to read this stuff anyway.
But in general:
1) I'm for creating a simple deployment spec that allows you to define
static pipelines declaratively. The decision middleware thing is just
an idea
On Sat, 2005-07-23 at 21:57 -0400, Phillip J. Eby wrote:
> > > For that matter, if you did that, you could specify the above as:
> > >
> > > [blaz.factory]
> > > config=blaz.conf
> > >
> > > [bleeb.factory]
> > > config=bleeb.conf
> >
> >Guess that would work for me, but out of
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]
> > >co
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_comp
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
> >factory = bleeb.factory
> >
> >[filter:blaz]
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
>factory = bleeb.factory
>
>[filter:blaz]
>config = blaz.conf
>factory = blaz.factory
That looks backwards to me.
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
>
>> 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
>>fact
Chris McDonough wrote:
> 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
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
> (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),
> IfTest(method=POST,Mim
Phillip,
100% agreed.
Libraries are more flexible than middleware because you get to decide
when, if, and how they get called. Middleware has its place, but it
doesn't make sense to try to package all library code as middleware.
Even when you do write middleware, it should simply link in libra
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 distingu
Hi, I have been looking at WSGI for only a few weeks, but had some
ideas similar (I hope) to what is being discussed that I'll put down
here. I'm new to this so I beg your indulgence if this is heading down
the wrong track or wildly offtopic :)
It seems to me that a major drawback of WSGI middlewa
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.
>
>
> A
It seems to me that authentication and authorization should be a put
into a library that isn't bound to the Web at all. I thought that
those guys reimplementing J2EE in Python did that. :-/
Oh well,
-jj
On 7/16/05, Chris McDonough <[EMAIL PROTECTED]> wrote:
> I've also been putting a bit of thou
Phillip J. Eby wrote:
> 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 b
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 eas
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-bran
Ian Bicking wrote ..
> There's several conventions that could be used for trying applications
> in-sequence. For instance, you could do something like this (untested)
> for delegating to different apps until one of them doesn't respond with
> a 404:
>
> class FirstFound(object):
> """Try app
Chris McDonough wrote:
> 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
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
A couple things I don't understand in this discussion.
Phillip J. Eby said:
> At 03:28 AM 7/17/2005 -0500, Ian Bicking wrote:
>>I guess I'm treating the request environment as that context. I don't
>>really see the problem with that...?
>
> It puts a layer in the request call stack for each servi
I tried to think of this today in terms of creating a "deployment spec"
but boy, it gets complicated if you want a lot of useful features out of
it. I have about four or five pages of a straw man "deployment
configuration" proposal, but it makes way too many assumptions.
So I tried to boil the pr
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 i
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 b
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
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
>>
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
>> applicati
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 pipeli
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
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 c
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 pr
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:
http://mail.python.org/mailman/options/w
35 matches
Mail list logo
