Proposal for Ruby on Rails for the SOC.

Hi list,

I'm sorry to come here talking about this (since I realize you have
many, far better things to do, but I'd really like your feedback on an
idea I have for the summer of code.

I'd like to work with the guys at Ruby Central on implementing a
feature for Ruby on Rails, and since you guys are the best source of
information on the subject, I'd like to ask you if you like my idea
and if you think it's possible to do this during the course of three
months.

I'd like to "improve debugging capabilities for Ruby on Rails" (that
will be the title of my application).

Right now, debugging a Rails application isn't really as smooth as it
could be. You can set up a breakpoint and start up a breakpoint client
and then access the page and that sort of works. If you haven't set up
a breakpoint, all you get is some information on an HTML page, which
sometimes isn't all that useful. If you're debugging Ajax-based apps,
sometimes you don't even get the HTML page to let you know something's
gone wrong. What you'd really like to be able to do is inspect the
state of the application at that point.

What I'd like to do is change what happens when you start script/
server and during its execution. Unless it's started in Daemon mode,
I'd like it to support a more REPL-based style of development. By
adding an option to script/server and/or the appropriate places
(config/environment.rb and friends) you should get behavior like this:

1) When a sucessful request is made, the behavior remains the same as
now. (the results are logged on screen)
2) When an error occurs, a page appears, similar to the 500.html page
that's currently shown in production. This page will instruct the
developer to check to console for additional details and a debugging
session.
3) On the console, the error message that would have been displayed
inside the HTML form is presented to the user.
4) He is then dropped in an Irb like environment, similar to what he'd
get if he were to set up a breakpoint. At this point, the server will
display an error message (something like 'Service temporarily
unavailable') on any other request that is made during the time of the
debugging session.
5) After inspecting the problem (and hopefuly fixing things) he could
call something like 'continue', which would exit the IRB session and
let the server return to its normal state.
6) Also, script/server should follow a similar behavior when meeting a
breakpoint, except for the HTML page which should be different.
7) The HTML pages should give the developer useful info on where to
direct his text editor (what file and line, for breakpoints, as well
as errors).

Some of this has been done with ruby-debug
http://blog.nanorails.com/articles/2006/07/14/a-better-rails-debugger-ruby-debug
but it would be great if this were integrated so that you could get
this kind of behavior each time your application hits an error. It
could use ruby-debug or the standard debug.rb, since I'm not really
that aware of all the details, at this point.

I believe this could be a great aid, both to application developers,
and to Rails developers.

So This is what I'd like to work on, this summer. I want to know if
you guys think this project is worth submitting an application for (if
you'd include it somehow, in core Rails, or if you'd like to have it
as a plugin or something). Mostly, I'd like to know if you like the
idea

I'd also like to know if you think it's possible (and doable), or if
you think three months is too much time to work on this.

I'd generally appreciate any form of feedback you guys can send my
way. I'd love to work on Rails for the google SOC and I'd really like
to have this kind of functionality in Rails.

Thanks.

Eugen.

Eugen,

I think this is an excellent idea.

It would be nice if it would be possible to send an os level signal (USR1/2?) to the application to toggle this feature on and off.

   ~Wayne

Great idea. I'd like this even for non browser initiated work.
reload! comes close to a full REPL, but not all the way - it would be
nice to type in some lines to the console, get a failure, change the
code, have it refreshed, and run all of those lines again.