On 2011-01-06 09:06:10 -0800,
chris.d...@gmail.com said:
I wasn't actually talking about the log dump. That was useful. What I
was talking about were earlier messages in the thread where people were
making responses, quoting vast swaths of text for no clear reason.
Ah. :) I do make an effort to trim quoted text to only the relevant parts.
On Thu, 6 Jan 2011, Alice Bevan–McGregor wrote:
https://github.com/GothAlice/wsgi2/blob/master/pep444.textile
Thanks, watching that now.
The textile document will no longer be updated; the pep-444.rst
document is where it'll be at.
I should have been more explicit here as I now feel I must defend
myself from frowns. I'm not talking about single methods that do the
entire app. I nest a series of middleware that bottom out at Selector
which then does url based dispatch to applications, which themselves
are defined as handlers (simple wsgi functions) and access
StorageInterfaces and Serializations. The middleware, handlers, stores
and serializers are all independently testable (and usable).
*nods* My framework (WebCore) is basically a packaged up version of a
custom middleware stack so I can easily re-use it from project to
project. I assumed (in my head) you were "rolling your own"
framework/stack.
That is already the case with filters, and will be when I ratify the
async idea (after further discussion here). My current thought process
is that async will be optional for server implementors and will be
easily detectable by applications and middleware and have zero impact
on middleware/applications if disabled (by configuration) or missing.
This notion of being detectable seems weird to me. Are we actually
expecting an application to query the server, find out it is not async
capable, and choose a different code path as a result? Seems much more
likely that the installer will choose a server or app that meets their
needs. That is: you don't need to detect, you need to know (presumably
at install/config time).
Or maybe I am imagining the use cases incorrectly here. I think of app
being async as an explicit choice made by the builder to achieve some
goal.
More to the point it needs to be detectable by middleware without
explicitly configuring every layer of middleware, potentially with
differing configuration mechanics and semantics. (I.e. arguments like
enable_async, async_enable, iLoveAsync, ...)
I can't get my head around filters yet.[snip]
Filters offer several benefits, some of which are mild:
:: Simplified application / middleware debugging via smaller stack.
:: Clearly defined tasks; ingress = altering the environ / input,
egress = > altering the output.
:: Egress filters are not executed if an unhandled exception is raised.
Taken individually none of these seem super critical to me.
Or to put it another way: Yeah, so?
(This is the aforementioned resistance showing through. The above
sounds perfectly nice, reasonable and desireable, but not _necessary_.)
It isn't necessary; it is, however, an often re-implemented feature of
a framework on top of WSGI. CherryPy, Paste, Django, etc. all
implement some form of non-WSGI (or, hell, Paste uses WSGI middleware)
thing they call a 'filter'.
Filters are optional, and an example is/will be provided for utilizing
> ingress/egress filter stacks as middleware.
In a conversation with some people about the Atom Publishing Protocol I
tried to convince them that the terms SHOULD and MAY had no place in a
spec. WSGI* is not really the same kind of spec, but optionality
still grates in the same way.
I fully agree; that's why a lot of the PEP 333 "optionally" or "may"
features have become "must". "Optionally" and "may" simply never get
implemented.
Filters are optional because a number of people have raised valid
arguments that it might not be entirely needed. Thus, it's not
required. But I strongly feel that some defined API should be present
in (or /at least/ referred to by) the PEP, otherwise the future will
hold the same server-specific incompatible implementations.
- Alice.
_______________________________________________
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
