On Tue, Dec 14, 2010 at 12:54 PM, Alice Bevan–McGregor <span dir="ltr">&lt;<a href="mailto:alice@gothcandy.com">alice@gothcandy.com</a>&gt;</span> wrote:<br><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">

<div class="im">
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
An application is an application and servers are imagined but not actually concrete.<br>
</blockquote>
<br></div>
Could you elaborate?  (Define &quot;concrete&quot; in this context.)</blockquote><div><br>WSGI applications never directly touch the server.  They are called by the server, but have no reference to the server.  Servers in turn take an app and parameters specific to there serveryness (which may or may not even involve HTTP), but it&#39;s good we&#39;ve gotten them out of the realm of application composition (early on WSGI servers frequently handled mounting apps at locations in the path, but that&#39;s been replaced with dispatching middleware).  An application wrapped with middleware is also a single object you can hand around; we don&#39;t have an object that represents all of &quot;application, list of pre-filters, list of post-filters&quot;.<br>

<br> </div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;"><div class="im">
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
If you handle filters at the server level you have to have some way of registering these filters, and it&#39;s unclear what order they should be applied.  At import?  Does the server have to poke around in the app it is running?  How can it traverse down if you have dispatching apps (like paste.urlmap or Routes)?<br>


</blockquote>
<br></div>
Filters are unaffected by, and unaware of, dispatch.  They are defined at the same time your application middleware stack is constructed, and passed (in the current implementation) to the HTTPServer protocol as a list at the same time as your wrapped application stack.<div class="im">

<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
You can still implement this locally of course, as a class that takes an app and input and output filters.<br>
</blockquote>
<br></div>
If you -do- need &quot;region specific&quot; filtering, you can ostensibly wrap multiple final applications in filter management middleware, as you say.  That&#39;s a fairly advanced use-case regardless of filtering.<br>


<br>
I would love to see examples of what people might implement as filters (i.e. middleware that does ONE of ingress or egress processing, not both).  From CherryPy I see things like:<br>
<br>
* BaseURLFilter (ingress Apache base path adjustments)<br>
* DecodingFilter (ingress request parameter decoding)<br>
* EncodingFilter (egress response header and body encoding)<br>
* GzipFilter (already mentioned)<br>
* LogDebugInfoFilter (egress insertion of page generation time into HTML stream)<br>
* TidyFilter (egress piping of response body to Tidy)<br>
* VirtualHostFilter (similar to BaseURLFilter)<br>
<br>
None of these (with the possible exception of LogDebugInfoFilter) I could imagine needing to be path-specific.<font color="#888888"></font></blockquote><div><br>GzipFilter is wonky at best (it interacts oddly with range requests and etags).  Prefix handling is useful (e.g., paste.deploy.config.PrefixMiddleware), and usually global and unconfigured.  Debugging and logging stuff often needs per-path configuration, which can mean multiple instances applied after dispatch.  Encoding and Decoding don&#39;t apply to WSGI.  Tidy is intrusive and I think questionable on a global level.  I don&#39;t think the use cases are there.  Tightly bound pre-filters and post-filters are particularly problematic.  This all seems like a lot of work to avoid a few stack frames in a traceback.<br>

<br></div></div>-- <br>Ian Bicking  |  <a href="http://blog.ianbicking.org">http://blog.ianbicking.org</a><br>