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/ --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" group. 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 -~----------~----~----~----~------~----~------~--~---
> 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 --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" group. 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 -~----------~----~----~----~------~----~------~--~---
On 2/17/08, Michael Koziarski <michael@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: joshknowles@gmail.com web: http://joshknowles.com --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" group. 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 -~----------~----~----~----~------~----~------~--~---
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. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" group. 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 -~----------~----~----~----~------~----~------~--~---
> 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 --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" group. 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 -~----------~----~----~----~------~----~------~--~---
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 > endI 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 --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" group. 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 -~----------~----~----~----~------~----~------~--~---
> 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 --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" group. 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 -~----------~----~----~----~------~----~------~--~---
On Feb 17, 2008 9:26 PM, Josh Peek <joshpeek@gmail.com> wrote:> 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.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 --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" group. 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 -~----------~----~----~----~------~----~------~--~---
On Feb 17, 2008 9:43 PM, Nick Sieger <nicksieger@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 --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" group. 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 -~----------~----~----~----~------~----~------~--~---
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:> On Feb 17, 2008 9:43 PM, Nick Sieger <nicksie...@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--~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" group. 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 -~----------~----~----~----~------~----~------~--~---
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. On Feb 18, 2008 1:20 AM, Jeremy Kemper <jeremy@bitsweat.net> wrote:> > On Feb 17, 2008 9:43 PM, Nick Sieger <nicksieger@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 > > > > >-- Tobi http://shopify.com - modern e-commerce software http://typo.leetsoft.com - Open source weblog engine http://blog.leetsoft.com - Technical weblog --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" group. 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 -~----------~----~----~----~------~----~------~--~---
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. On Feb 18, 2008 6:20 AM, Jeremy Kemper <jeremy@bitsweat.net> wrote:> > On Feb 17, 2008 9:43 PM, Nick Sieger <nicksieger@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 > > > > >-- Cheers! - Pratik http://m.onkey.org --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" group. 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 -~----------~----~----~----~------~----~------~--~---
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!
On Feb 18, 8:47 pm, Pratik <pratikn...@gmail.com>
wrote:> 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.
>
> On Feb 18, 2008 6:20 AM, Jeremy Kemper <jer...@bitsweat.net> wrote:
>
>
>
>
>
> > On Feb 17, 2008 9:43 PM, Nick Sieger <nicksie...@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
>
> --
> Cheers!
> - Pratikhttp://m.onkey.org
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Core" group.
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
-~----------~----~----~----~------~----~------~--~---