Re: [boost] [RPC] Compile-time reflection for RPC and mocking
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
Peter Bindels writes: 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
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@gmail.com>:
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
participants (2)
-
Brian Wood -
Oleg Labutin