qpid-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Frank Quinn <fquinn...@gmail.com>
Subject Re: Alternatives to pn_messenger (QPID Proton C)
Date Wed, 03 May 2017 20:48:33 GMT
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, <astitcher@apache.org> wrote:

> On Wed, 2017-05-03 at 17:27 +0100, Robbie Gemmell wrote:
> > On 3 May 2017 at 08:55, Frank Quinn <fquinn.ni@gmail.com> 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
>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message