Yup its all open source: Middleware: https://github.com/OpenMAMA/OpenMAMA/tree/master/mama/c_cpp/src/c/bridge/qpid
Payload: https://github.com/OpenMAMA/OpenMAMA/tree/master/mama/c_cpp/src/c/payload/qpidmsg Its an API to provide a unified interface into a variety of (mostly market data) middlewares and payloads, so writing a payload bridge for c++ would effectively be a rewrite. Cheers, Frank On Wed, 3 May 2017, 22:49 Andrew Stitcher, <[email protected]> wrote: > On Wed, 2017-05-03 at 21:27 +0000, Frank Quinn wrote: > > Thanks Andrew, > > > > Our application distinguishes between transport and payload. We have > > a > > *lot* of code around the payload which happily works with > > pn_message_t > > which would be extremely painful to port to the C++ API. We then use > > pn_messenger purely for transport send / recv. > > Is it possible to see this code anywhere? I'm curious what sort of > volume of code you are talking about. > > Is code actually using the pn_message_t API extensively? Or is it > creating a binary message that gets put in the message, or in some > message properties? > > Is it using the pn_data_t API? - If you are using complex AMQP > datastructures via pn_data_t then that might be complex to recode. > > IMO the proton::message API ergonomics are so much easier and better > than the pn_message_t that I would hardly consider using pn_message_t > anymore. > > However I understand that working code is working code. > > If don't want to change the pn_message_t using code then using the > proactor directly might be the way to go. > > Andrew > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > >
