[Web-SIG] Standardized configuration

[mso@oz.net]

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 service you want to
> offer, versus *no* layers for an arbitrary number of services.  It adds
> work to every request to put stuff into the environment, then take it out
> again, versus just getting what you want in the first place.

But the "overhead" is adding one dictionary item and reading it again.
The most insignificant thing imaginable.  More important is the ugliness
of accessing an arbitrarily-named key in the application, but even that is
minor.

> The difference is obliviousness; if you want to *wrap* an application not
> written to use WSGI services, then it makes sense to make it
> middleware.  If you're writing a new application, just have it use
> components instead of mocking up a 401 just so you can use the existing
> middleware.

That seems to suggest the whole PEP 333 excersise was a waste of time. 
(I'm not saying it is, just that it seems to be the logical conclusion of
your statement.)  WSGI is just "backward compatibility" for existing
applications?  Practically all the interesting middleware falls into this
"component" category.  I'm having a hard time seeing what middleware a
naive CGI/legacy application would benefit from, besides access to
alternative webservers.  (But at this point, none of these are "better"
than the frameworks' native servers.)  Especially since legacy apps access
their services in a framework-specific way and would need specific
middleware or patching.

If a new API is in order, it seems high priority to get a PEP out soon, or
at least some reference implementations.  Otherwise the middleware way
will become a de facto standard.

-- 
-- Mike Orr <mso at oz.net>