Hi Yigong,
 

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.

This is for calls to functions and not member-functions. I shouldn't call my library doing Remote Procedure Calls, but Remote Member Calls.

The approach using futures is one thing, i'd like to implement, too, since everything needed for that is already in place.

One thing i don't like about that library is, that you need to provide the interface explicitly multiple times:
reg.set<int (int)>("inc", inc);
rpc::call<std::string, int (int)> call_inc__1("inc",  1);

This could be improved using variadic templates (or boost::fusion).

 
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.

Can more than two channels connect?

If so, consider A connected to B, B connected to C. Does A see C and can communicate with it? 

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".

This sounds very much like Plan9.

Can the namespace-model be built upon a normal RPC-library without much effort?

I assume, that something like a dynamic name->id resolver added to the RPC-library provides just what you want.  Instead of native references, the objects need to be addressed by the "names". When an object changes its id, the resolver publishes that information and the calls go to the "new" target. Although defining abstract interfaces for such an implementation is still a good idea and in the long run better than having multiple implementations with incompatible interfaces.
 
RPC is a really important in many domains, although i talked mostly about Channel above. Please keep up your good work!

Thanks, I will.
Siegfried