Re: problem with input filter and POST data (fileupload)

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