[Web-SIG] Standardized configuration
ianb at colorstudy.com
Tue Jul 19 19:28:21 CEST 2005
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 be useful, your application has to be able to depend on its
>> availability so it can't be "oblivious".
> Exactly. As soon as you start trying to have configured services, you
> are creating Yet Another Framework. Which isn't a bad thing per se,
> except that it falls outside the scope of PEP 333. It deserves a
> separate PEP, I think, and a separate implementation mechanism than
> being crammed into the request environment. These things should be
> allowed to be static, so that an application can do some reasonable
> setup, and so that you don't have per-request overhead to shove ninety
> services into the environment.
The services themselves can be fairly lazy; though unfortunately you
can't be trickly and add laziness when a service was originally written
in a very concrete way, since that would require fake dictionaries and
other things WSGI disallows.
But there's not a lot of overhead to environ['paste.session.factory']()
-- it's just a stub object stuck in a particulra key, that knows the
context in which it was created so it can communicate with that context
> Also, because we are dealing not with basic plumbing but with making a
> nice kitchen, it seems to me we can afford to make the fixtures nice.
> That is, for an add-on specification to WSGI we don't need to adhere to
> the "let it be ugly for apps if it makes the server easier" principle
> that guided PEP 333. The assumption there was that people would mostly
> port existing wrappers over HTTP/CGI to be wrappers over WSGI. But for
> services, we are talking about an actual framework to be used by
> application developers directly, so more user-friendliness is definitely
> in order.
My own vision for most middleware is that it get wrapped by frameworks.
In fact, that it be so godawful ugly you can't help but wrap it ;)
Well, not deliberately horrible for no good reason... but at least that
it doesn't matter that much, because the frameworks will want to wrap it
This is the "aesthetically neutral" aspect of middleware that I've
mentioned before. People get all bothered if you use underscores
instead of mixed case, or vice versa, even though that's one of the
least important aspects of the features being implemented.
Of course, there are real problems with wrapping. Like it reduces the
transparency -- middleware becomes this magic part of the system because
it's not something people deal with day-to-day, and if your first chance
to work with middleware is to write it, that's intimidating. There's
also the leaky abstraction problem; though I think well-defined
middleware helps avoid this.
Really, if you are building user-visible standard libraries, you are
building a framework. And maybe I'm just too pessimistic about a
standard framework... but, well, I am certainly not optimistic about it.
On the other hand, it's not like people are breaking down my door with
their enthusiasm to use Paste middleware either. So I dunno.
I can only say a good strategy clearly has to build on developer's
laziness, their fear of new things, and their reluctance to learn new
things. Well, that's the negative way of saying it. It has to build on
the likelihood that their attention is primarily focused on their
domain, that it builds on their existing knowledge, and that it presents
a minimal set of new concepts.
Ian Bicking / ianb at colorstudy.com / http://blog.ianbicking.org
More information about the Web-SIG