|
Joerg
jerch at rockborn.de
Mon Feb 16 08:38:44 EST 2009
Am Monday 16 February 2009 06:07:37 schrieben Sie: > BTW, am still interested to know what the input filter does. the input filter was a special wish of a customer to get a file upload status bar in the web app. it works like this: - get a unified upload ID (given as GET var) and contentlength - read length of stream data per time to get the stats like bytes sent, throughput - indicate a stilling running upload with a bool var as long as EOS was not sent (i had to catch IOErrors here, if the client closes the connection prematurely) - write this all into a tempfile - get the stats with a second request (via ajax) > In mod_wsgi will most likely be adding ability to optionally hook into > Apache handler phases much like mod_python, except for content phase > which would be WSGI, but without all the extra crud on top that > mod_python has. Also been thinking about supporting filters, but since > am less convinced about the usefulness of them given performance > concerns, would like to know what you using filters for. i did some work on output filters, mainly for caching purpose. i stumbled into this, because my psp templating was lacking the ability to return me the created content. the output filter was an easy way to implement a whole page cache, but for partial caching it was useless again. i solved this later by hooking the req.write() method with my own one. i dont know, how wsgi handles incoming data, but i think the upload bar thing is a must have for the clients and should be implemented by the browsers (to give the user a neat upload bar they could provide a js-api to those stats). it is definitively the wrong way it is nowadays. also the latter case for caching is not a big problem anymore in wsgi, since you can daisy-chain the "handlers" and hook into the row some cache functionality wherever you want. (but my actual understanding of this is quite poor since i have just started to look into it) joerg
|