On Fri, Jul 5, 2013 at 8:32 PM, Eric Wong <normalperson@yhbt.net> wrote:

"James Tucker (Google Drive)" <jftucker@gmail.com> wrote:

> This is a straw man start of the Rack 2 design doc / todo list.

I think small, gradual improvements are the way to go.

That said, I think everything on the list seams reasonable.

Am I correct the input body will remain IO-like (and not
callback-driven, so evented servers can avoid buffering the body?)
Likewise for streaming responses via response_body.each

On input, almost certainly.

I'm quite unhappy with the streaming output complexities today, though. I want to try out some APIs and see which will be reasonable for real world use. I certainly want to avoid making changes unless there are significant benefits, and I also don't want to add excessive complexity to the trivial cases for the sake of these "modern" special cases.

Those would be the only major API/design change/incompatibilities I can
think of, but perhaps theyd'd break too much existing code to be called
Rack.

I'm also considering some forward looking changes to the env hash, particularly in light of how some things may change with http 2, and also with an eye to increasing efficiency for servers/parsers populating these structures.

--

---
You received this message because you are subscribed to the Google Groups "Rack Development" group.
To unsubscribe from this group and stop receiving emails from it, send an email to rack-devel+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.