On Thu, 16 Sep 2010, jason kirtland wrote:
The 'pegboard' middleware composes a result out of an arbitrary graph
of WSGI apps, with one request visiting many applications. The graph
can be built at runtime in application code, so it would be very
difficult to report all of the '.app's applicable for a given environ
until after the request. Also, it is quite reasonable in practice to
have middleware both in front of such a composer and also in the
stacks of the apps it composes.
The general rule we can extract from this is that we don't want the spec
to limit what is possible for the sake of making fairly arbitrary things
that only some people (think they?) need and can be satisfied using
the more fundamental units already present in the design.
I can see that applying here, thus we don't want to enforce some kind of
"app" method or attribute as that could be costly for assembling
flexible groups of apps (in the same app).
On the other end of that same principle, I'm not sure I can see
much justification in (paraphrase) "let's make the return signature
be the same as the signature of some constructors at use out there
in the wild".
One of the best things about WSGI, that I hope does not get lost in
Web3 (thanks for moving things forward, by the way), is that in its
most basic use it is almost entirely about (simple) data structure
and (simple) data flow and not about methods, objects, magical
attributes and other flim flammery.
In other words it is good that the units are basic and fundamental.
--
Chris Dent http://burningchrome.com/
[...]
_______________________________________________
Web-SIG mailing list
Web-SIG@python.org
Web SIG: http://www.python.org/sigs/web-sig
Unsubscribe:
http://mail.python.org/mailman/options/web-sig/archive%40mail-archive.com
