Re: [boost] Interest in Remote Procedure Call Library?

Subject: Re: [boost] Interest in Remote Procedure Call Library?
From: Daniel Larimer (dlarimer_at_[hidden])
Date: 2010-02-08 00:45:38

> I am curious about this too, a good reflection system for C++ (I still
> have no clue why it does not have one built-in, would simplify so much
> of Boost's work) would be quite useful, but I still wonder why you
> have one in an RPC library.

I include one in my RPC library because the "API" of the server is auto-discovered by the client which pairs up method calls based upon the exposed function signature.   I allow discovery of network services by both name AND "type/interface".  If both sides were implemented in C++ then I would be fine and would not need the method names; however, the underlying protocol is implemented in labview and C for embedded.  This ability to publish your "API" to is critical for CORBA or DBUS and other RPC systems.   

Effectively the protocol is "self documenting" and "auto discoverable" with the intent of making it scriptable.   If you are implementing an XML based RPC then you would want the signature to be human readable... but I suppose all of that functionality could be handled by the delegates.  

In reality though, the "cost" of adding "reflection" to the RPC interface amounts to 2 lines of code to expose the #NAME of the method passed to the function macro and the interface macro.   

You are right, perhaps this is a separate requirement from RPC; however, from the perspective of my fellow developers having to register the methods once for RPC and a second time for scripting would be annoying.  

Another requirement I should add is "non-obtrusive".   The developer user of the API should not have to do anything more than say "expose this instance to the network under this name" other than specify the meta information one time.

Under your system, the user would have to define multiple RPCHandler's, register the same functions twice to get two instances.   Thus they would probably create a function to "create" their global rpc.  Correct me if I am wrong, but wouldn't your user need to register all of the methods in the interface 2x if they wanted to expose it to RPC AND to a scripting engine?  

I have seen Boost.Fusion mentioned several times, and started to look into it.  An amazing concept!  I started playing with BOOST_PP today and it is amazing as well.  Reducing code and eliminating bugs!  

With respect to synchronous vs asynchronous, it is really the end user's choice.   The previous version of my library was "single threaded" and thus could not be synchronous unless the user waited by recursively calling the main event loop which caused all kinds of re-entrant problems.   The new version is multi-threaded so the user can "block" until data comes in and boost::asio will still process the packets.   Feedback from my co-workers is that synchronous is much easier and creating a chain of handlers is a lot of work if you have N operations that depend upon the completion of the previous operation (we need libdispatch on windows!).   So any library should support both.   One time "start up calls" can be synchronous while mission critical calls are not.   Plus, the user has the choice to "invoke without return" or "invoke without guarantee" or "invoke without order".   This allows the underlying transport to pick between TCP/UDP/Sequence Numbers/Acks/etc.   

Based on initial response it appears that there are about 3-4 people interested in the topic.   I still need to gather support for open sourcing our code (something I want to do as primary developer).  So if anyone else is interested in working on such a library and preparing it for boost then speak up.  

Dan

On Feb 7, 2010, at 9:29 PM, OvermindDL1 wrote:

> I am curious about this too, a good reflection system for C++ (I still
> have no clue why it does not have one built-in, would simplify so much
> of Boost's work) would be quite useful, but I still wonder why you
> have one in an RPC library.