[Web-SIG] [Python-Dev] Adding wsgiref to stdlib

[Luke Arno]

On 5/2/06, Ian Bicking <ianb at colorstudy.com> wrote:
> Luke Arno wrote:
> > I don't pipe up much but dispatch has been on my
> > mind for a while as I have been working on this:
> >
> > http://lukearno.com/projects/selector/
> >
> > I think dispatching is best left as an (obvious) exercise
> > to the reader. What dispatching makes sense, what
> > metaphor or technique should be applied, is situational.
>
> I don't think the idea is obvious to readers.  Prefix dispatching is
> also unique, in that it's the only kind of dispatching that can be
> represented fully in conventional WSGI (without other environ keys);
> though host matching also pretty much works.
>

I think it is obvious.

I can't count the number of times I have seen a
novice web developer create a "master" PHP
script to push his/her whole application through in
an effort to take over dispatch. I think that it
is the most natural thing to do.

> Prefix matching also doesn't compete very actively with other
> dispatching techniques.  It's not enough to build a framework on, it
> represents a technique that already exists in lots of web servers
>

I am not concerned with competition but with clarity.

Including this in the code could be interpreted as
saying "this is how dispatching is done with WSGI."
The right message, from my perspective is
"dispatching is not part of WSGI."

I think some intelligent mention of the
issue of dispatch in the docs would be more
constructive than a lame default. Maybe dispatch
could be demonstrated in the docs rather than
actually included in the code base?

>
> > When I see other WSGI servers requiring a list of
> > prefix/app pairs in their init signature, I am put off.
> >
> > The server's job is to translate HTTP (or SCGI, FCGI,
> > etc.) to WSGI. Just do that.
>
> This isn't being proposed as part of the server, just as a tool in
> wsgiref.  It's up to the user to use the dispatcher together with the
> server.  It's part of other servers,
>

Still. It seems crufty and potentially misleading.

> > To me WSGI is not just the freedom of frameworks
> > interoperating, but the freedom _from_ frameworks.
> > The stack can be unbundled and I can pick the the
> > best thing for my needs at each layer, à la carte.
>
> This is still unbundled.

It is a looser bundle but a bundle still.

> I think that including an unbundled dispatcher
> actually can help encourage more unbundled dispatchers outside of the
> standard library.

I am not sure how. Instead of creating their own and
learning, users may be trying to kluge around what
they feel like they are "supposed" to be using.

>
> Without a prefix dispatcher available and easily referenced in the
> documentation, I think people will see wsgiref as incomplete and silly,
> because it's ingrained in people that the web server does dispatching.
> Another problem is if they don't use WSGI/CGI conventions for what
> prefix dispatching implement on their own, which means that they won't
> be as compatible with other webservers and environments.
>

As you say, the idea of dispatch is already
ingrained, so the need _will_ be obvious. ;)

I don't see how the user could miss that they
need to do dispatch somehow (especially if it says
so right in the docs). Not providing a lame default
invites them to think a little about how _they_ want
to do it.

Daniel Boorstin said:
"The greatest obstacle to discovery is not ignorance
  -- it is the illusion of knowledge."

Users _do_ expect a framework to provide
dispatching capability, of course.

But this is a server not a framework. No one
should think it is "silly" or "incomplete" for not
doing more than its job.

Finally, I think our disagreement is rather small
for all this text. All I am trying to say is that I think
an example in the docs would be much more
useful than an implementation included in the
code, in this case.

Either way, I am happy that we will have the server
in the standard lib. Whatever Phillip decides to do
is fine with me.

Cheers,
- Luke