Has anyone looked into including Rack in Rails? Most of the other web frameworks seem to be onboard with it (Merb, err).
Has anyone looked into including Rack in Rails? Most of the other web frameworks seem to be onboard with it (Merb, err).
I'm prepared to say I'm missing something, but from where I sit ut's an interesting idea, but I don't see what we'd get over the current use of cgi.rb?
class LifoAdapter def call(env) rack_response = Rack::Response.new rack_request = Rack::Request.new(env) cgi = Rack::Adapter::Rails::CGIWrapper.new(rack_request, rack_response) ActionController::Dispatcher.dispatch(cgi, ActionController::CgiRequest::DEFAULT_SESSION_OPTIONS, rack_response) rack_response.finish end end
fundamentally they appear to do exactly the same thing with different key names?
Ezra wrote up a nice post on why they're using Rack for Merb (1). I especially like the cascading dispatchers.
We'd gain support for other adapters, however, I don't really care that much as I'm stick with Mongrel for now. But, yeah, I was wondering the same thing, are there any speed advantages? Seems like everyone is always bashing the built in CGI lib.
We'd gain support for other adapters, however, I don't really care that much as I'm stick with Mongrel for now.
We already have fastcgi, and thin can already run a rails app? Again I can see the nice idea, but right now it doesn't necessarily buy us anything. Should that change, perhaps it's worth looking into.
But, yeah, I was wondering the same thing, are there any speed advantages? Seems like everyone is always bashing the built in CGI lib.
Everyone beating up on something isn't a particularly reliable predictor for it being slow, or poorly implemented. Again, if there's a compelling benefit maybe we change.
I think the advantages would come if some enterprising individual were to look at writing a rails dispatcher based solely on Rack, and discarded all the cgi-based innards. Does such a thing seem possible?
/Nick
I think the advantages would come if some enterprising individual were to look at writing a rails dispatcher based solely on Rack, and discarded all the cgi-based innards. Does such a thing seem possible?
There'd need to be new request and response subclasses and new session management infrastructure. But it's certainly not an insurmountable task.
Similarly someone could wrap up ServletRequest and ServletResponse using the same basic approach.
Ruby's cgi.rb is crufty and difficult to extend, but its only substantive slowness is multipart mime parsing. I'd prefer a separate streaming mime parser, really.
Rack is essentially a cleanup of the same interaction pattern along with a growing grab bag of web-related tools like request dispatch, url mapping, static file service, session handling, etc.
I like its aesthetics for the most part, but I dislike the wsgi-style request/response convention (duck typing plz) and I'm apprehensive of its early feature bloat.
jeremy
Very. AbstractRequest has some CGI-ish expectations, but Rack meets them all. The existing session stores rely on CGI::Session, but that could be changed without too much trouble.
We only really use CGI as a standard way of getting an environment and input stream for the request and a an output stream to send the response. There's nothing particularly magic or arcane about working with some other env/input/output webby API.
jeremy
It would probably be a tad faster since the stubbing of cgi would not be required anymore, but that's not a good reason to switch probably.
The main advantage is simplicity, for implementing handlers and plugging stuff together.
It would definitely remove and cleanup code in the dispatcher. And it
would make the life of webserver developers easier 
(yeah that very
important, ok?)
I agree that rack is a good idea and while I don't completely agree with it's interface, i really like the premise of a common web-server to framework abstraction in the ruby world.
As jeremy pointed out it's unfortunate that rack seems to be succumbing to early feature creep. If the project could be split into a basic dispatching library and a tools library there would be a good chance for inclusion into ruby standard library.
I'm in the camp of "too early to jump the rack wagon". Having said that, I don't have a lot of problems with Rack's interface. Only major advantage of Rack ( not from webserver developer's eye ) I can see is that it'd make it very easy to extend rails applications. You can write a rack handler for some crazy performance optimization and it'll work on every web server. Currently, that's not possible with Mongrel handlers.
Having said that, I'm not quite sure how comfortable I'd be to depend on an external library ( which is not in corelib ) for the very basic workings of a framework as large ( not just in terms of loc ) as Rails. This approach might be ok for premature frameworks. But we're way past that.
Basically, we'll need to vendor Rack and not change it at all. So, why not just fork it instead ( removing things we dont need, designing api the way we all like ).
Just thinking out loud.
Rack is mainly a set of specifications. You don't need to require 'rack' to use it. Specially w/ adapters.
This is a Rack adapter:
app = proc { |env| [200, {} "Look ma', no Rack gem!"] }
All you have to do is have a call(env) method and return an array of [status, header, body] in your dispatcher. The Rack gem just include some cool stuff you can use like helpers and wrappers.
You don't NEED the Rack gem to follow Rack conventions (<= magic word), it's plain ol' Ruby yo!
