Hello,


i'm currently writing a library for making remote procedure calls to
C++ objects.
 
FYI, last year Stjepan spent quite some time on a rpc library, have you had a chance to look of it? (https://svn.boost.org/trac/boost/browser/sandbox/rpc). I remember he implemented asynchronous calls and use futures<> to implement synchronous calls. If you search last year's email, you may find good discussions about this rpc lib.


I'll have a closer look on what can be merged with "channels" from the
boost vault[1], but from the first look it seems that "channels"
targets a much more general approach. After the first tries, i
realized, that my implemention has to be very specific (e.g. templates
only where necessary). So, the design approaches might be too
different.
 
Yes, the Channel lib i am working on has a quite different target. It intends to define / provide the basic primitives for message passing (various name-spaces and dispatchers), and a template framework to compose these primitives and create customized message passing systems for specific applications. And the resulted messaging systems should be quite simple.

Channel generated messaging systems are peer-peer systems, not like the client-server model of RPC. When 2 remote channels connect, the ids / names in these 2 channels are exchanged automatically thru Channel's protocol, so threads / objects connected with these channels can do messaging with remote peers transparently.

Another big difference is the use of "names" / "ids". In normal rpc systems (or rpc based systems such as Corba), the only purpose of object names/urls or name-server is for "boot-strapping" - obtaining the inital reference to remote server object, after that, names/urls has no use. In RPC systems, the interface of components are the remote methods exposed by server objects (defined in IDL).
In Channel, "names/ids" and name-spaces provide the major design scheme / framework for distributed systems. The interface of a component in distributed systems are what "ids" it publish and what "ids" it subscrib to, its physical location doesn't matter much. A component running inside a process "A", attached to a channel and pub/sub some ids, can easily be moved to another process "B" in a different machine, as long as "B" has a channel which connect to "A"'s channel. The component will function as normal as it was in process "A".

RPC is a really important in many domains, although i talked mostly about Channel above. Please keep up your good work!

Regards
Yigong