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

Subject: Re: [boost] [RPC] Compile-time reflection for RPC and mocking
From: Damien Buhl (damien.buhl_at_[hidden])
Date: 2014-12-08 14:50:03

Hi Peter,

Were you at the meetingcpp in Berlin ? I also was there, sad that we
didn't got in contact, because I've been working on such kind of things
for a while now (many years, from compiler plugins for gcc, clang to a
c++-only / macro / template metaprogramming version).

I would find it nice to see something good solving the issue of remote
procedure call and data field synchronization, because I've a
not-so-much working solution that I want to opensource at some point
when it will be good enough, but it would be of great benefit to get
others ideas/impl, because I've been essentially working alone and I'm
at the 5th rewrite already. :p

In any case I would be really interested on such a library. For example
you could use mechanisms like BOOST_FUSION_ADAPT_STRUCT to
"automatically" introspects classes in order to generate as well
serialized output and function calls. We could even add extensions to
fusion to allow more introsprection of adapted types.

What I want when I'll get my last changes on BOOST_FUSION_ADAPT_STRUCT
working on MSVC too, is to improve it in order to have it automatically
generate the boilerplate code to implement compile time reflections
proposals to iterate over structs or adt fields, bases etc. And to
implement an API near to the proposals ones.

I'm wondering how I could use Abel's Sinckovicks metaparse library to
improve the emulation for compile time reflection support, so that it
don't need to specify fields manually.

I think there already is Boost.Rpc in the sandbox, but I feel it didn't
evolved much lastly or am I wrong ? Do you meant basing your work on it ?

Regarding Boost HPX, I believe they already is an internal library for
this kind of automatic remote rpc, did you mean to use their serializers
based on spirit and so ?

I've always been dreaming of things like : auto remote_obj =
std::make_remotely_shared<MyClass>();

remote_obj->call_remote_service();
remote_obj->remote_field = "assign it remotely";

So yes I would definitely love to see others people working on these
points, and could even give a hand because I anyway invest weekly time
in this topic alone in my cellar :) .

Cheers,
--
Damien Buhl
On 12/08/2014 03:27 PM, 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?
> 
> Best regards,
> Peter Bindels
> 
> _______________________________________________
> Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
>