Cool, I was hoping the Rack thing was still in play. So some initial questions after looking at your Gist and reviewing Aaron's slides, but before diving into the existing Rack API:
Technical: - I like the clear separation of "on the way in" vs "on the way out" in yours. - Aaron's Filter objects have more of a lifecycle focus and explicit parameters - e.g. Filter is initialized (I guess Rack creates each middleware object here?), its #write gets called with explicit body, status, headers, and it gets a #close callback. Are you intentionally simplifying that, and does that have any implications for the HTTP streaming callback problem? - Likewise, what about the lifecycle hooks? - I'm still not quite clear on why stack depth has a huge GC impact, having never developed GC's myself. Is it literally the number of stack frames that slows things down, or is it that stack depth implies a large number of objects that need marking as each frame makes local copies of the application state and modifies the request/response? - The history of Ruby GC tools is long and storied, but it seems the current generation of tools is railsbench with skaes's rvm-patchsets, ruby-prof with its GCdata patch, and/or perftools. Yes? - How important is it to target each Ruby version? We don't drop 1.8 support till 4.0. Do you see this as a 4.0 timeframe project or a 3.2 timeframe project? The GCs are vastly different, of course, and I don't know enough to know if that will imply different strategies. I'm most worried about discovering that some strategy gives great results in 1.9.3 (hurray lazy sweeping) but has pathological implications for 1.8. Have you thought about that yet? - While we're making sweeping API changes, I want to do it right, and I don't have a lot of experience with the implications of seemingly-innocent Ruby choices. Any good mailing lists, blogs, etc. I should read up on? I'm thinking of stuff along the lines of Ernie Miller's Enumerable discovery: http://erniemiller.org/2011/07/16/benchmarking-rubys-enumerable/ Logistical: - What has the Rack team's response to these ideas been? It ain't broke, it is broke but this ain't it, we're working on it too? - And thus, do you see this as going back into Rack, or as Rails providing a meta-unRack (your Rick?) as the lowest-layer middleware, calling new-style APIs instead of old APIs and never letting Rack call the application? - What do you see as the migration path from old to new? Aaron's speech mentioned backwards-compatibility. Do you think newly-enlightened middleware will just expose both APIs, with old Rack calling one and new Rack calling the other? Or should the compatibility layer be built into R[ai]ck, as I asked above? -- You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" group. To view this discussion on the web visit https://groups.google.com/d/msg/rubyonrails-core/-/GDC4tG1HmpIJ. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en.
