In the comment section, the ".new" part after Rack::Signals is not needed (testing in 1.0.0)

First thing, it is using instance variables as shared memory so threads would be overriding each other. Secondly the when ready trap would not wait until all the threads have finished, it “might” just call it after the first thread does.

This was designed for multiprocess environments like cgi/fcgi.

Very. What happens if you DO use this in a threaded environment?

Wow. That’s interesting.

Exactly, I’m not against the feature, but the discussion is up on the mailing list already anyway.

From the sound of it, looks like manveru’s objection is to the code and not the feature itself. Which is valid. If 10 lines can comply with the same spec, and is faster, why not.

I think converting “foo[bar]” into ruby’s foo[‘bar’] is a lot more than convention. It’s common sense.

I’m with @manveru on this one. Minus 1 for rack core. This parsing strategy is based on a convention that just happens to be shared by more than one framework. This makes it ideal for rack-contrib. Placing it in rack core makes a statement about rack – that it is more than just an interface between web apps/frameworks and the web server, and that it is the appropriate place for shared code. I view rack as more of an interface than an abstract class, but yield to Christian and the rest of the core team to weigh in on the core principles defining what goes into core.

Please voice your opinion! https://groups.google.com/group/rack-devel/browse_thread/thread/732e2c1e014bde30

@visionmedia I’ve adapted Merbs parser for Rack. Its pretty small and pretty fast (you know those Merb guys ;) Please +1 the ticket I posted.

-1?? why? it belongs in core, then people can stop creating weird solutions like the rails one lol, rack core can just supply good/small/fast solution

-1 for rack-core. Seriously, one can make the given specs pass with like 10 lines of code.

Sinatra’s with a few modifications would be the cleanest that I have come across. _why’s is not bad either but you cant really read it and its slower

+1 for Rack core, -1 for using this exact code. I added it for my own purposes, but I think it’s too large and opinionated for Rack

Nested params on Rack::Request or Rack::Utils should definitely be considered for rack core. Huge +1 to that. In the meantime, rack-contrib can provide middleware / utilities.

If we bake it into Rack::Request, it can be much simpler and faster. Its much more difficult to post process the hash than to just parse the original query string.

https://rack.lighthouseapp.com/projects/22435/tickets/3-add-support-for-nested-params-parsing-in-rackrequest

Yikes that implementation is pretty large, has anyone benchmarked this? I doubt its a big deal but if it were to big in core as fast as possible would be nice, unless its really not an issue

Second what he said

+1 Rack Core :)

(doesn’t have to be the Rails implementation though)

It should be “before Filter2” in the second ‘before’ call