Eden Li wrote:
> Yes :)  The cool thing about this is you can get an irb shell right
> into the ruby process running rails, which means you can do all sorts
> of useful stuff like twiddling class variables and inspecting your
> controller states directly.
> 
> Probably a bad idea to do this in production, but could be useful
> during development.

Precisely. It's not intended to be exposed remotely. I've no idea what 
DRb's ACL stuff offers etc, but that could be looked at.

The idea was to be able to execute code inside a running ruby 
application. Initially this was because I had rails running as a windows 
service, and wanted to debug the different environment.

One of the things my (internal) rails app does though, is being a job 
process monitor, for scripts largely written in ruby. I can set some 
flag, that allows me to not just hook into and monkey patch rails live 
:), but also to capture exceptions in a running job, and rescue it 
providing this sort of simplistic remote debugging.

At any rate, while it was easy to write, it seems a few things didn't 
work with DRb as I thought they should.

I would've imagined that I could simply pass a local 
ReadlineInputMethod, and StdioOutputMethod to the remote IRB::Irb#new, 
but in fact that still did both input and output remotely - hence the 
kind of cumbersome proxies.

Remote output still didn't work, but that seems to be an IRB issue.

-- 
Posted via http://www.ruby-forum.com/.