[Backgroundrb-devel] Could a BackgrounDrb worker do this?

Bill Walton bill.walton at charter.net
Tue Sep 12 10:45:08 EDT 2006

Hi Ezra,

Continuing our conversation from the Rails list.

Ezra Zygmuntowicz wrote:
<snip some very encouraging stuff>

> Bill Walton wrote:
> > ... but could it work like....
> >
> > 1) from the rails app, start a worker for a session
> >  with a timeout setting and a controller/action argument
> > 2) every time the visitor interacts with the rails app,
> > reset the worker's timeout
> > 3) when the timeout occurs, the worker invokes the
> > controller/action in the rails app that was passed in at
> > startup.

> Something like this could work. The main issue is that
> backgroundrb doesn't use http so it can't really call a
> controller method in your app for you. You could just
> put a similar action in your worker class and call it there.

I'm not sure I'm understanding you here.  Are you saying put the 'cleanup' 
action that deletes the user-entered records and files in the worker?  If 
so, doesn't that go against the DRY principle?  Or are you saying to move it 
from where it is now (in one of the app's controllers) into a worker?

I'm definitely confused by your statement that "backgroundrb doesn't use 
http so it can't really call a controller method in your app".  I understood 
that workers could respond to Ajax requests.  Did I misunderstand?

To my limited understanding, if a worker's job is to respond to Ajax 
requests, that means I can think of a backgroundrb worker as just another of 
the app's controllers, albeit a 'special' one because it's running in 
parallel.  Am I 'courting danger' with this simplistic view?

Now that we've talked about it a little, I guess if it *is* ok to think 
about a worker as one of the app's controllers, then the worker really is 
where I want to put the cleanup code.  I'm also assuming that a worker 
'knows' what session it's part of.  Is that right?

Does any of the way I'm thinking about this tell you I'm heading off 'into 
the weeds'?


> Ok all that being said, BackgrounDRb can do the same
> thing for you. [...]  If you decide to go the BackgrounDRb
> route then please join the mailing list for it and I'll do my
> best to help you along.

Well.... here I am! ;-)  And thank you.  You may yet convince me that the 
script/cron route is the way to go.  But first, I need to better understand 
what you're telling me.  In the interest of full disclosure, until finding 
RoR around the first of this year, I've not done any serious development in 
a dozen years.  I've been managing it, but not doing it.  A lot has changed 
and I'm finding there are lots of details I need to learn.

Best regards,

*Mailing list: http://rubyforge.org/mailman/listinfo/backgroundrb-devel


You received this message because you are subscribed to the Google Groups 
"Ruby on Rails: Talk" group.
To post to this group, send email to rubyonrails-talk at googlegroups.com
To unsubscribe from this group, send email to 
rubyonrails-talk-unsubscribe at googlegroups.com
For more options, visit this group at 

More information about the Backgroundrb-devel mailing list