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 rubyonrails-core@googlegroups.com.
To unsubscribe from this group, send email to
rubyonrails-core+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/rubyonrails-core?hl=en.