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

Subject: Re: [boost] [RPC] Compile-time reflection for RPC and mocking
From: Oleg Labutin (ol.labutin_at_[hidden])
Date: 2014-12-09 18:05:53

   Ok I promised yesterday short explanation of RPC implementation in hl
library
please see attachment, it's short demonstration how we can make first step
to implement custom RPC approach. Obviously we should implement backend
(similar JsonBackend) and your compile time reflection based RPC on your
custom format will works ..^) Short time and very quick
   Please download hl library, and make project able to compile, I guiess
we can use more specific files, but it need more time to make that.

   Please be informed that this approach enable make full information about
functions signatures, name of arguments and types which registered in the
RPC system during compile time. Therefore you can choose any manipulation
for your personal data inside RPC system, maps, compiletime lists, maps
bindings, lambda, with classes <> without classes factory, futures. It's
abstract layer of compiletime reflection based RPC.

    The are two lines below is quintessence of approach

    typedef hl::manual_extract<impl::Services>::type services;
    typedef hl::refl_extract<impl::interface_first::ftbl >::type functions;

   Mb\ backend part of hl_ipc is difficult to understanding and using, I'll
hope we can discuss how it can be improved.

As I remember my first explanation was here
http://lists.boost.org/Archives/boost/att-210788/hl-introduction.cpp

P.S. Currenlty I use chrom GUI for send email, and I don't know which
messages can be overkvoted

2014-12-09 22:02 GMT+02:00 Brian Wood <woodbrian77_at_[hidden]>:

> Peter Bindels writes:
>
> > 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 tend to agree with Bjorn's post about messaging middleware.
> For some reason, thinking in terms of messages is easier for
> me.  For example, rather than serializing the name of the interface
> and function, I include a message id, which is often one byte.
>
> --
> Brian
> Ebenezer Enterprises - So far G-d has helped us.
> http://webEbenezer.net
>
> _______________________________________________
> Unsubscribe & other changes:
> http://lists.boost.org/mailman/listinfo.cgi/boost
>