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?
--
Cheers
Koz
Ezra wrote up a nice post on why they're using Rack for Merb (1). I
especially like the cascading dispatchers.
1) http://brainspl.at/articles/2008/02/16/so-merb-core-is-built-on-rack-you-say-why-should-i-care
--
Josh Knowles
phone: 509-979-1593
email: joshk...@gmail.com
web: http://joshknowles.com
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.
--
Cheers
Koz
>
>> Has anyone looked into including Rack in Rails? Most of the other web
>> frameworks seem to be onboard with it (Merb, err).
>>
>> http://rack.rubyforge.org/
>
> 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
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
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.
--
Cheers
Koz
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
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.
--
Tobi
http://shopify.com - modern e-commerce software
http://typo.leetsoft.com - Open source weblog engine
http://blog.leetsoft.com - Technical weblog
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.
--
Cheers!
- Pratik
http://m.onkey.org