Sun Oct 5 18:14:52 CEST 2008
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 /
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...
Vlad Dumitrescu wrote:
> On Sat, Oct 4, 2008 at 15:43, Serge Aleynikov <> wrote:
>> Actually I see what's missing in Java/OTP.NET implementation. These
>> features are documented here:
> 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
>> 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,
More information about the erlang-questions