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.

> the problem is that the DRb client is creating instances in the =
server-side that are not hold themselves in the server-side but only =
referenced in the client-side using some kind of a proxy to the object =
that is only present in the server-side. Even if I could somehow mark =
those objects transparently to remain alive, I'd still have to figure =
out a way to detect when no references exist to it any longer in the =
client-side so that I could free those objects in the server-side as =
well or the server-side will leak.
>=20
> That's why I think this must be implemented in the DRb specification =
itself or it wouldn't be feasible to implement in away that would be =
transparent for the user.

The server should not hold on to its objects if the client crashes, but =
how do you separate a crash from a network partition?

The answer to this question is very much dependent upon the application =
you build atop the protocol.  There is no one correct answer for all =
possible uses of DRb, so it should not be part of the protocol.

> My real goal is for the user in the client-side to have a feeling that =
he's programming directly in the server-side, just using DRb as a proxy =
to allow him to use features only available in the server-side. That =
includes creating temporary objects that should be freed once no =
references exist to them in the client-side.

One option is to use an LRU-backed id converter with a smart client that =
can recreate objects for lost references.

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.=