Re: [boost] [RPC] Compile-time reflection for RPC and mocking

Subject: Re: [boost] [RPC] Compile-time reflection for RPC and mocking
From: Edward Diener (eldiener_at_[hidden])
Date: 2014-12-08 14:43:14

On 12/8/2014 9:27 AM, Peter Bindels wrote:
> Hi all,
>
> I've searched through the Boost mailing list history to find related emails
> and the last I found was from January where Oleg Labutin and Hartmut Kaiser
> discussed compile-time reflection in the context of RPC mechanisms.
>
> Based on Hartmut's speech last Saturday introducing HPX and explaining a
> bit about async/future/promise I tried to implement a simple RPC mechanism
> that uses then to decouple work and the result I have so far is very
> promising. I have a simple interface with a call that returns a future, and
> the caller does not distinguish between calling the actual object and
> calling on a proxy, as both return a future<T>. It does what the discussion
> mentions - serialize the name of the interface and function, as well as the
> arguments (basically the mangled name of the interface function) to ensure
> there are no mismatches.
>
> I would like to take this oppurtunity to propose two things:
>
> - I can work on this idea to work it out into a full RPC mechanism, to be
> proposed for Boost.RPC, if there is enough interest. Currently it uses
> macros to generate and wrap functions, and a simple serializer that
> serializes in the same way that Protobuf and Thrift also serialize.
> - Given a compile-time reflection method, the entire proxy class and
> dispatch class can be auto-generated from the interface class - the full
> code for registering an interface with the RPC mechanism would collapse to
> RPC::Register<T>(); To do so, it would need two language additions. It
> needs access to a compile-time iterator over functions and traits about the
> argument types, return type, name and whether it is a virtual function. For
> the prototype this can be manually generated for an interface to show it
> works. Additionally, it would need to be able to use such a definition to
> instantiate a virtual function from a base class - basically, hooking up an
> std::function<X> to a virtual function X directly. I think this is
> well-implementable (probably reusing most code from lambdas for the link
> code), but I don't know whether that's true.
>
> On the second note, I also proposed a Mock library a few years ago. This
> basically fell flat on the code that I suggested being very unsafe and
> using many hackish methods to mock functions. Using the compile-time
> reflection proposed for the second bullet I would be able to replace the
> entire hackishness from that with 100% compliant code, with only one minor
> regression in functionality. That should make it Boost-OK at least from a
> language standards perspective.
>
> Any ideas? Reactions on RPC or Mocking?

I worked on a programming project under Windows a number of years back 
involving RPC and I remember how difficult it was to get everything 
correct using standard C++, VC++, and IDL. So I can definitely see the 
use for a Boost RPC which would make implementing RPC interfaces using 
template programming much easier.