To read all comments associated with this story, please click here.
Kaj-de-Vos,
"Leaking of implementation details is detrimental to interfacing with other hardware architectures"
I understand all your initial criticisms, however I'm curious how an RPC interface leads to leaking of implementation details?
Corba interfaces are completely portable across many languages/platforms, including scripting languages.
Heck, just using corba itself would provide instant RPC compatibility with almost all serious languages out there.
If corba is too heavy weight to use in the OS, one could still provide an OS binding for it - that might even be a novel feature for the OS.
In RPC, you assume that the remote end has a procedure you can call. That's a big assumption. To make it work, you assume that the remote procedure is written in the same programming language. That's a huge implementation "detail".
Remote objects are just an object oriented extension of the RPC concept. They were en vogue in the nineties, when everybody switched to remote architectures. This was when CORBA and other such methods were found to be too cumbersome.
Messaging has a long history, really. These lessons were already learned in AmigaOS, BeOS, Syllable and new messaging systems such as 0MQ. You can also ask yourself what the most successful remote protocol does. Is HTTP/HTML RPC based?





Member since:
2010-06-09
I'm not really interested in spending a lot of time discussing this, sorry. You asked for warnings, and this is mine. We could argue endlessly about the details, but it boils down to this: the abstraction level of declarative messaging is higher than RPC. Leaking of implementation details is detrimental to interfacing with other hardware architectures, binding with other languages, and interfacing with historical versions of interfaces on the same language and hardware architecture. Therefore, a higher abstraction level is desirable.