Re: [boost] [rpc] Introducing Boost.Reflect, Boost.CMT, and Boost.RPC

Subject: Re: [boost] [rpc] Introducing Boost.Reflect, Boost.CMT, and Boost.RPC
From: Daniel Larimer (dlarimer_at_[hidden])
Date: 2011-07-28 15:53:40

On Thu, Jul 28, 2011 at 2:49 PM, Antony Polukhin <antoshkka_at_[hidden]>wrote:

> 2011/7/28 Daniel Larimer <dlarimer_at_[hidden]>:
> > I have just recently completed my first alpha release of a generic RPC
> > library designed to support different protocols (JSON, XML, Protocol
> > Buffers) and different transports (UDP, TCP, HTTP) in a generic manner.
>
> Sounds great!
>
> > Lastly all of this builds on top of my Boost.CMT (Collaborative
> > Multi-Tasking Library) which seems to be along the same lines as Oliver's
> > Boost.Strand library, but with a simpler interface.  It is built on top
> of
> > Boost.Context.  This allows the RPC to be asynchronous, thread-safe, and
> > free of nasty completion handlers.
>
> You don`t use asio, is you code portable to other operating systems?
> Can it be tuned, to use asio/libev?
>

It uses Boost.ASIO for all networking.  I just wrap Boost.ASIO async calls
with
Boost.CMT 'coroutine' handlers such that an async call becomes a
future/promise instead
of a callback.  This way there is no need to worry about threading issues.

>
> > I have documentation of all three libraries posted here.
> >
> > http://bytemaster.github.com/dev/modules.html
>
> I took a quick glance. Looks like "alpha release", but it is possible
> to understand the idea.
>
> This looks like not a safe approach:
> void operator()( Member Class::*p, const char* name )
> You serialize no info about function parameters.
>

Depends upon which visitor you are using.  If you are visiting all of the
functors on a boost::reflect::vtable as used by
boost::reflect::any_ptr<Interface> then Member is a
boost::reflect::mirror_member<> specialization (a functor) and therefore
Member::fused_params -> boost::fusion::vector<paramtypes>    or
Member::traits -> boost::function_traits.

https://github.com/bytemaster/boost_reflect/blob/master/examples/cli.hppline
29  shows how to print out the function signature for the member.

If you are using boost::reflector<T>::visit( visitor ) and you expected your
visitor to handle member functors then your visitor would need
specializations for each different
number of parameters (or veridic templates).

In practice I find that for interfaces I am using the vtable of functors in
any_ptr<Interface> and for data types (structures) that I use as parameters
I am only reflecting public members and not functors.   For an example of
how reflection serializes structs see:
https://github.com/bytemaster/Boost.RPC/blob/master/include/boost/rpc/json.hppline
94.

>
> I`m interested, but now I have no projects were it is possible to use
> your library.
>
> Best regards,
> Antony Polukhin
> _______________________________________________
> Unsubscribe & other changes:
> http://lists.boost.org/mailman/listinfo.cgi/boost
>