Thanks for the quick responses folks! Those comments help a lot. Honestly for our use case, we're happy to go lower level. In fact that's usually where we integrate our bridges - the messenger approach was more of an exception in our case and we actually suffered a little from it at the start because there was no way to hook into things like connection and disconnection events and it all felt very synchronous and batchy. Similarly though we were bitten by a fair few interface changes to pn_messenger in the earlier days and keeping cross-version compatibility in tact and I'm just conscious of trying to adopt at this point if the interface is still being ironed out. Sounds like it might be best to wait until the next release if we go down the proactor route.
We also make heavy use of pn_message_t which I thought might have been a possible overload for the c++ proton::message constructor but I can't see one unless there are conversion functions somewhere public? Cheers, Frank On Wed, 3 May 2017, 20:43 Andrew Stitcher, <[email protected]> wrote: > On Wed, 2017-05-03 at 17:27 +0100, Robbie Gemmell wrote: > > On 3 May 2017 at 08:55, Frank Quinn <[email protected]> wrote: > > > Hi Folks, > > > > > > I look after the OpenMAMA bridge for Qpid Proton C and we > > > originally built > > > our API based on the pn_messenger interface. However I see that > > > interface > > > is now marked for deprecation, so I'm looking for alternatives. I'd > > > appreciate any feedback on my assessment of the options available > > > which are > > > listed below. > > > > > > When I look at the alternative options available in > > > https://github.com/apache/qpid-proton/tree/master/examples/c, the > > > options > > > seem to be between: > > > > > > *Messenger:* Deprecated - so let's assume that's going away and not > > > an > > > option > > > *Proactor: *Looks interesting, though no subscription level support > > > and > > > looks to be experimental > > > *Reactor: *I think the proactor pattern looks like a better fit for > > > us due > > > to its asyncronous nature, but this looks to be more stable? (or at > > > least > > > not marked as experimental?) Again, light on subscription > > > integration > > > though. > > > > > To emphasize Robbie's points: > > * We are actively working on the proactor as a replacement IO layer for > reactor which will be deprecated in due course. > > * The messenger API is high level and not really comparable with the > proactor/reactor APIs which are significantly lower level. > > * The closest API to the same level of abstraction is the C++ binding, > however it does split apart the concept of network connection address > from message address, which makes for a different "API feel". It sounds > that in your case this might fit your requirements better. > > The C++ API is mostly stable currently, especially for client purposes. > But we plan that when we release 0.18 the API will stabilize further > and will shift on top of the proton proactor IO rather than the reactor > IO. > > HTH > > Andrew > >
