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

[Ezra Zygmuntowicz]

On Sep 13, 2006, at 7:38 AM, Bill Walton wrote:

> Hi Ezra,
>
> Ezra Zygmuntowicz wrote:
>
>>> Continuing our conversation from the Rails list.
>>
>> Welcome ;)
>
> Thanks!
>
>>> Does any of the way I'm thinking about this tell you I'm heading  
>>> off 'into the weeds'?
>>
>> Yes you have a few incorrect notions,
>
> I was afraid of that ;-)
>
>> let's see if I can clear things up for you a bit.
>
> I really appreciate it.  I should warn you though.  Sometimes even  
> *I* am surprised by my density ;-)
>
>> Your backgroundrb worker are not rails controllers at all and they  
>> do not directly respond to ajax calls. In your rails app you have  
>> access to the MiddleMan object that you can  use to start workers  
>> in the drb server and ping them for results  later during the ajax  
>> requests.
>
> If I can ping the worker from the controller and they can respond  
> and my controller can receive and process their response, and  
> they're sitting out there running and waiting to respond, I'm not  
> getting why they couldn't *initiate* a 'conversation'.  Is this a  
> 'we don't have a tool built to do that' situation?  Or is it 'the  
> Rails architecture doesn't allow for that kind of interprocess  
> communication' situation?

	I'm just not sure what you are trying to accomplish with this. I  
think you are making it way more difficult ;) The way backgroundrb  
works is mainly a one way thing. You kick off the workers from your  
controller and then you can ping the worker later from your  
controller to get status or results from it. If you really feel you  
need to call back to your controller from the bgdrb server, you could  
use net/http in ruby's standard library top make a http request back  
to the rails app.

	The problem with trying to talk back to rails from the drb server is  
that rails is not persistent. Each request instantiates a new  
controller object. So if you try to callback to rails from bdrb, you  
aren't garanteed to get the same controller object to work with. So  
bdrb works by letting rails control it. You kick off your worker  
classes with a command in your controller and then you store a job  
key in your sessions. Then on later requests in rails you can use  
this job key to grab a handle on your worker object and call methods  
on it for results.

>
> <snip>
>
>> So IU hope that explains it a bit better.
>
> I have a much better understanding of how to use BackgrounDRb.   
> Thank you. But I'm still confused ;-(
>
> I think, maybe, my confusion comes from associating (in my mind)  
> BackgrounDRb and dRuby (drb) as discussed in "Programming Ruby".   
> The DRb class description (p.670) says "Although expressed in terms  
> of clients and servers, once the initial connection is established,  
> the protocol is effectively symmetrical: either side can invoke  
> methods in objects on the other side."  Could you shed some light  
> on this for me?

	Yes BackgrounDRb uses drb to do its work. But the way it is designed  
is for use with the way rails works. Its a persistent daemon that  
runs your jobs. Your rails controllers and models are all  
instantiated on each request so they don't persist and thats why you  
need a session.

	So yes its true that the way drb works is that both ends effectively  
become servers and clients. But because rails is a web app, and the  
way request/response and object instantiation in rails works, you  
can't really call back to rails from backgroundrb. Because the place  
you would be trying to call back to won't exist after its request is  
served.


Cheers-
-Ezra