4 ms·

Not nearly impossible. Was put in the jdk like 20 years ago. RMI: https://en.m.wikipedia.org/wiki/Java_remote_method_invocation https://en.m.wikipedia.org/wiki/

Not nearly impossible. Was put in the jdk like 20 years ago. RMI: https://en.m.wikipedia.org/wiki/Java_remote_method_invocation https://en.m.wikipedia.org/wiki/Java_remote_method_invocatio...

shawnz 7y ago
Another example is Distributed Smalltalk from 1987
macintux 7y ago
It’s impossible to make RMI behave exactly like local method invocation. It introduces many error cases and performance challenges you don’t normally have to consider.
jerf 7y ago
There have been dozens or hundreds of things called "remote method" or "remote procedure" or "remote function" invocation. However, not a single one of them has overcome the fundamental problem that you can not have something that is semantically identical to the function call presented by programming languages, because programming language functions simply do not have the concept that you are accessing it over a network, and they take heavy and critical advantage of the resulting simplifications. Someone more clever than wise may stand up and point out that technically even a local function call is unreliable in many of the same ways that a network call is. However, even if many of the same problems can theoretically arise, the distribution of the problems are fundamentally different, which is why you do not guard every single function call in your program for all the network-type errors, and it generally works, whereas if you program that way in a networked environment, it generally does not work. Personally I've come to prefer messages very strongly to "RPC" as the foundation of a system. Messages can trivially implement an RPC-like system, but RPCs can not implement a message-like system. Even if you implement an RPC called "SendMessage", you're still adding synchronization on the RPC system sending over the call and waiting for the response. Among other things, but that's the big one.
- macintux 7y ago
  Much like you can implement TCP (or something like it) atop UDP but you can’t really do the reverse.
protomyth 7y ago
also NeXT's Portable Distributed Objects which continued into the OS X and D'OLE had some of this

Not nearly impossible. Was put in the jdk like 20 years ago. RMI: https://en.m.wikipedia.org/wiki/Java_remote_method_invocation https://en.m.wikipedia.org/wiki/Java_remote_method_invocatio...

shawnz 7y ago

Another example is Distributed Smalltalk from 1987

macintux 7y ago

It’s impossible to make RMI behave exactly like local method invocation. It introduces many error cases and performance challenges you don’t normally have to consider.

jerf 7y ago

There have been dozens or hundreds of things called "remote method" or "remote procedure" or "remote function" invocation. However, not a single one of them has overcome the fundamental problem that you can not have something that is semantically identical to the function call presented by programming languages, because programming language functions simply do not have the concept that you are accessing it over a network, and they take heavy and critical advantage of the resulting simplifications. Someone more clever than wise may stand up and point out that technically even a local function call is unreliable in many of the same ways that a network call is. However, even if many of the same problems can theoretically arise, the distribution of the problems are fundamentally different, which is why you do not guard every single function call in your program for all the network-type errors, and it generally works, whereas if you program that way in a networked environment, it generally does not work. Personally I've come to prefer messages very strongly to "RPC" as the foundation of a system. Messages can trivially implement an RPC-like system, but RPCs can not implement a message-like system. Even if you implement an RPC called "SendMessage", you're still adding synchronization on the RPC system sending over the call and waiting for the response. Among other things, but that's the big one.

macintux 7y ago
Much like you can implement TCP (or something like it) atop UDP but you can’t really do the reverse.

protomyth 7y ago

also NeXT's Portable Distributed Objects which continued into the OS X and D'OLE had some of this