[Web-SIG] Standardized configuration

[Ian Bicking]

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 
later.

> 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 
anyway.

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