Rack up Rails

[Josh Peek]

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/

[Michael Koziarski]

> 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

fundamentally they appear to do exactly the same thing with different key names?

--
Cheers

Koz

[Josh Knowles]

On 2/17/08, Michael Koziarski <mic...@koziarski.com> wrote:
> 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?

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

[Josh Peek]

On Feb 17, 10:44 pm, "Michael Koziarski" <mich...@koziarski.com>
wrote:

> 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?

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.

[Michael Koziarski]

> 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.

--
Cheers

Koz

[Nick Sieger]

On Feb 17, 2008, at 10:44 PM, Michael Koziarski wrote:

>
>> 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

[Michael Koziarski]

> 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.

--
Cheers

Koz

[Jeremy Kemper]

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

[Jeremy Kemper]

On Feb 17, 2008 9:43 PM, Nick Sieger <nicks...@gmail.com> wrote:
> 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?

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

[macournoyer]

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?)

On Feb 18, 1:20 am, "Jeremy Kemper" <jer...@bitsweat.net> wrote:

[Tobias Lütke]

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.

--
Tobi
http://shopify.com - modern e-commerce software
http://typo.leetsoft.com - Open source weblog engine
http://blog.leetsoft.com - Technical weblog

[Pratik]

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.

--
Cheers!
- Pratik
http://m.onkey.org

[macournoyer]

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!