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=92s no comprehensive documentation, but it=92s 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.
>=20
> 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 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.

>> One option is to use an LRU-backed id converter with a smart client =
that can recreate objects for lost references.
>=20
> 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 thing 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.
>=20
> 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=85

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=92s basically the same as performing id conversion, but =
you=92ll 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.=