C nodes

[Vlad Dumitrescu]

> >I guess so, but there is quite some things that a node must do to be a
> >"real" erlang node. For a short list right out of the head: rpc, file,
> >global, global_group, dist_ac, application, application_controller.
> >There are probably a lot more.

> I think what is really needed is a framework for specifying
> distributed protocols and handling unsupported services. We may want
> to have this between Erlang nodes as well. In most applications so
> far, the networks of Erlang nodes have been pretty homogeneous, often
> with the very same boot script executing on all nodes. I think many
> will want to depart from that in the future.

I agree with Ulf here. As a matter of fact, as I see things, there are two different issues: the Erlang VM and the network/distribution mechanism.

To me, they seem only loosely connected. It should be possible to completely split the two apart and then for example use something else than Erlang to actually run the code. Of course, not with the same elegance and simplicity, but the big benefit would be that ports would be replaced by true nodes and the clumsy communication mechanism with ports would be replaced by TCP/IP (as default). I think that would only add to the elegance of the system. 

Of course, that would lead to heterogenous networks, with nodes that might only be able to run a single process, or don't have the same modules available, but in a truly distributed world, that should be closer to the reality than not... 

In conclusion, is it possible (without rewriting the whole system) to separate the Erlang VM from the underlying networking runtime, and use thet runtime as a base for non-Erlang nodes?

cheers, Vlad