Consider allowing the handler to see response's output stream

[mtopolnik]

I am working on a high-throughput RESTful web service that serves database records as JSON. The results are streamed to the client directly from the db to prevent unbounded heap growth. Ring currently accepts two forms of streamed data: lazy sequences and input streams. When there are resources associated with the response stream, the lazy seq is out of the question because it cannot be "closed" until entirely consumed, so we are left with the input stream, its main problem being that it is reactive -- data is pulled from it. There are two paths here: implement your own input stream that gradually fetches from the db to serve the incoming reads, or have a PipedInputStream/PipedOutputStream combo. The former imposes an awkward programming model that produces exceedingly complex optimized code; the latter requires two threads per response stream and introduces coordination oveheads. (Mind you, the overhead is suprisingly low -- about 3% -- but when scaled to hundreds of concurrent responses, occupying say 400 instead of 200 threads is another story.)

The most elegant way -- both as the programming model and from the performance standpoint -- would be to allow the ring handler access to the response's output stream, so it can push its data directly into it. The only issue is whether this constitutes an api barrier breach.

[weavejester]

This would require a change to the ring spec, so this is not a trivial change, and would be best discussed on the Ring Google group.

Other people have suggested this change in the past, but the problem with using an OutputStream is that it limits you to blocking I/O. A more flexible solution is to use a returned function as a way of performing asynchronous I/O:

http://groups.google.com/group/ring-clojure/browse_thread/thread/243f452c915356c8