I didn't go in to this in much detail in my article, but I'd like to follow up with my long term plan for this feature. I think that buffered responses are a special case of streaming responses (they're streaming responses with one chunk), and I'd like to make this API the underpinnings of the response system in Rails.<p>One of the things that I think Rack got wrong and that J2EE, Node.js, etc got right is that the response bodys should be treated as IO objects. Whether the IO object streams, buffers, gzips, etc is up to the IO object. Regardless, the API remains the same.<p>I hope to eventually push the concept of an IO response up to Rack itself and eliminate this code from Rails.
I don't want to be a wet blanket here, but does anyone else find this "tender love making" branding all over Aaron Patterson's technical content a bit... distracting?<p>Personally I do. That said, Aaron does amazing work and he should be able to brand it however he likes. I'm also very grateful for what he gives to the community.<p>So, am I just an old fuddy-duddy, or what? I mean, personally, I actually enjoy it, despite the distraction, but I'm surprised that this seems to be such a non-issue to everyone else.
I really respect the hard work going in to the evolution of Rails, but it does feel like some new features should be considered as Gems.<p>The hardest part of managing mature software is keeping it lean.
I find it curios that he does not mention Thin as a webserver which is good for streaming. Thin was perhaps the first ruby webserver which got good support for streaming responses. While Rainbows! and Puma might be better at least Thin should deserve a mention due to its popularity alone. It is way more downloaded than both Rainbows! and Puma together.<p>Is there some problem with running Thin together with stream in rails 4?