[Backgroundrb-devel] Could a BackgrounDrb worker do this?
bill.walton at charter.net
Tue Sep 12 10:45:08 EDT 2006
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
> 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.
*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