[Web-SIG] Standardized configuration

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

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.

For WSGI itself, the server-side implementation has to be very server 
specific.  But the bulk of a service stack could be implemented once (e.g. 
as part of wsgiref), and then just used by servers.  So, we don't have to 
worry as much about making it easy for server people to implement, except 
for any server-specific choices about how configuration might be 
stacked.  (For example, in a filesystem-oriented server like Apache, you 
might want subdirectories to inherit services defined in parent directories.)


>OTOH, the primary benefit -- to me, at least -- of modeling services as
>WSGI middleware is the fact that someone else might be able to use my
>service outside the scope of my projects (and thus help maintain it and
>find bugs, etc).  So if I've got the wrong concept of what kinds of
>middleware that I can expect "normal" people to use, I don't want to go
>very far down that road without listening carefully to Phillip.  Perhaps
>I'll have a shot at influencing the direction of WSGI to make it more
>appropriate for this sort of thing or maybe we'll come up with a better
>way of doing it.
>
>Zope 3 is a component system much like what I'm after, and I may just
>end up using it wholesale.  But my immediate problem with Zope 3 is that
>like Zope 2, it's a collection of libraries that have dependencies on
>other libraries that are only included within its own checkout and don't
>yet have much of a life of their own.  It's not really a technical
>problem, it's a social one... I'd rather have a somewhat messy framework
>with a lot of diversity composed of wildly differing component
>implementations that have a life of their own than to be be trapped in a
>clean, pure world where all the components are used only within that
>world.
>
>I suspect there's a middle ground here somewhere.

Right; I'm suggesting that we grow a "WSGI Deployment" or "WSGI Stack" 
specification that includes a simple way to obtain services (using the Zope 
3 definition of "service" as simply a named component).  This would form 
the basis for various "WSGI Service" specifications.  And, for existing 
frameworks there's at least some potential possibility of integrating with 
this stack, since PEAK and Zope 3 both already have ways to define and 
acquire named services, so it might be possible to define the spec in such 
a way that their implementations could be reused by wrapping them in a thin 
"WSGI Stack" adapter.  Similarly, if there are any other frameworks out 
there that offer similar functionality, then they ought to be able to play 
too, at least in principle.