[erlang-questions] jinterface

[Serge Aleynikov]

While we are on the subject, I was looking at the hierarchy of classes 
in jinterface/otp.net and have some design questions.

1. OtpSelf and OtpNode inherit from OtpLocalNode.  Only OtpNode 
implements OtpMbox support.  Consequently OtpSelf can't create a mailbox 
and use its send/receive functions.

It looks like it would make more sense if OtpSelf inherited from 
OtpNode, so that if would have access to all mbox / registerName / 
whereis goodies.

2. OtpCookedConnection and OtpConnection inherit from 
AbstractConnection, but only OtpConnection has sendRPC/receiveRPC and 
only OtpCookedConnection keeps track of established links.

It would make more sense if OtpConnection inherited from 
OtpCookedConnection so that OtpNode can do sendRPC/receiveRPC calls and 
also be aware of link management offered by OtpCooked Connection.

Perhaps I am missing something but it's not clear from this class 
hierarchy what the intent of the designer was...

Serge

Vlad Dumitrescu wrote:
> On Sat, Oct 4, 2008 at 15:43, Serge Aleynikov <saleyn@REDACTED> wrote:
>> Actually I see what's missing in Java/OTP.NET implementation.  These
>> features are documented here:
>> http://www.erlang.org/doc/apps/erts/erl_dist_protocol.html#9.7
> 
> Even if those features were implemented, the Java VM is still not the
> BEAM VM, so it wouldn't be te same anyway. The impedance mismatch
> between the two runtime models is too large to integrate them
> seamlessly.
> 
>> Actually, my overall goal was to establish the reverse - monitor an Erlang process
>> from a .NET client (or java), where the client implements a UI application that
>> establishes subscription with a process for receiving events of some sort, and
>> tries to reestablish subscription if it detects that the remote process died.
> 
> Then you are in luck, because it can be done! Start a process that
> will do the monitoring and let it forward the messages to the Java
> side. This proxying technique can be applied in many other contexts,
> too. For example, for the io:format problem, you can start a io server
> that works as a proxy for the missing one on the Java side. But you
> may find soon that you will prefer to move more and more functionality
> on the Erlang side and use Java just as a presentation layer.
> 
> best regards,
> Vlad
>