It's unfortunate this doesn't just use JSGI, which is much closer to Rack/WSGI than Connect, and has a fair amount of usage in Node (https://github.com/joyent/node/wiki/modules#wiki-middleware-...), as well as other server-side JavaScript platforms (Ringo, Akshell, Pintura, Narwhal)
I'd love to hear the reasoning for the differences between the two.
JSGI is not able to take advantage of node's ability to serve responses asynchronously because the spec doesn't allow for it. JSGI specifies that the return value of an app must be the [status, headers, body], whereas Strata specifies that the return value of an app is not important and that the app's callback should be used to serve the response instead.
My JSGI implementation in Common Node (https://github.com/olegp/common-node) uses node-fibers allowing it to stream out responses without blocking the event loop.
In fact, by connecting an input stream to an output stream (forEachable objects), the underlying code automatically enables Node's pipe like behavior.
Even so, this breaks down with JSGI middleware that depends on running in a Java environment. For example, JSGI's gzip middleware uses Java's byte buffers.
Which JSGI gzip middleware are you referring to? It should use portable CommonJS Binary objects, which in Common Node's case wraps Buffers and in RingoJS (Java) byte arrays.
Kris Zyp's "jsgi-node" absolutely does support streaming. As does Kris Kowal's "q-http" and "jaque" framework.
There have been lots of discussion on asynchronous/streaming in JSGI, but perhaps it hasn't made it's way into the specs you've looked at. Promises are one way, fibers are another.
Foreach-able "streams" w/ promises and Node streams are pretty much equivalent (and yes, JSGI w/ promises can handle back pressure, though I'm not sure if there are any public implementations yet)
I'd love to hear the reasoning for the differences between the two.
(Disclaimer: I started JSGI)