Em 20-01-2014 21:51, Eric Hodel escreveu:
> On 18 Jan 2014, at 15:12, Rodrigo Rosenfeld Rosas <rr.rosas / gmail.com> wrote:
>> Em 17-01-2014 19:53, Eric Hodel escreveu:
>>> On 17 Jan 2014, at 04:22, Rodrigo Rosenfeld Rosas <rr.rosas / gmail.com> wrote:
>>>> I guess the problem is that I didn't quite understand what you meant by this id_conv thing even after looking at the examples you pointed me to. Are there any comprehensive documentation about this feature?
>>> There?s no comprehensive documentation, but it?s not a particularly complex feature.  You implement to_id to convert an object to a reference and to_obj to convert a reference to an object.  How you do this depends on the needs of your application.
>> I still don't understand what you mean. Should I override Object#to_id and #to_obj in the DRb server-side to get this transparent proxy to work somehow?
> Have you read the id_conv samples that ship with ruby?
>
> $ ag -l id_conv sample/drb/
> sample/drb/gw_s.rb
> sample/drb/holders.rb
> sample/drb/name.rb

The problem is that as far as I understand this id conversion will only 
take place for objects tranferred between the drb server and client, 
right? My concern is that with a generic drb server that will evaluate 
arbitrary code in the server-side there are good chances more objects 
will be created in the server-side that are not referenced by any of the 
objects transferred over DRb, don't you agree?

>> The approach described in that article is that Ruby code is "eval"ued in the DRb server side (running JRuby). I can't easily track what intermediate objects have been created by the eval code on arbitrary code sent by the client-side.
> The id conversion feature allows you to track such intermediate objects.

All of them, even if they are not transferred back to the DRb client? 
How would DRb know about them?


>>> One option is to use an LRU-backed id converter with a smart client that can recreate objects for lost references.
>> I would have no idea on how to recreate a lost object I don't even know about (it was generated by a generic "eval" call anyway).
> This is what id conversion tracks (as mentioned above).
>
>> And I don't really think this would be possible as those objects were generated as part of an algorithm and I'd need to re-run the algorithm to recreate the object most likely.
> Fair.
>
>>> Another option is to have the client create a context object on the server that the client allocates and communicates through.  The context object will hold temporary objects and can be cleaned up automatically through a keep-alive mechanism after the client disconnects.
>> This would be so complex that it wouldn't worth to implement a client that could easily run arbitrary code in the DRb server with access to the JVM?
> It could just be a proxy object that wraps all calls to the underlying API and ensures that only tracked references are returned to the clients.  It?s basically the same as performing id conversion, but you?ll know when the client disconnects so you can drop all references.  You should be able to wrap any protocol generically with such a context object regardless of the communication mechanism.

This has the same concern as the id conversion approach. I'm not sure if 
keeping a reference only to the returned objects would be enough or if 
there could be any cases where the returned objects don't hold any 
references to other possible required intermediate objects created in 
the process... I can't think of an example right now, so maybe this 
can't help, I'm just not confident enough about that...

But in the case where the returned DRb objects will always hold a 
reference to all required objects created in the server-side, there 
remains another problem. How do I detect that the objects have been 
collected in the client-side so that I could free them in the 
server-side as well? This has always been my main concern with regards 
to manually keeping a reference by artificial means in the server-side.

Anyway, thank you for pointing me more details about what to look at in 
those samples. That certainly helped me to understand what you meant by 
id conversion.

Cheers,
Rodrigo.