Mailing-List: contact users-help@qpid.apache.org; run by ezmlm
Precedence: bulk
Reply-To: users@qpid.apache.org
DMARC-Filter: OpenDMARC Filter v1.3.2 mx1.redhat.com 986CF79917
Message-ID: <1493840605.5473.6.camel@apache.org>
Subject: Re: Alternatives to pn_messenger (QPID Proton C)
From: Andrew Stitcher <astitcher@apache.org>
To: users@qpid.apache.org, fquinn.ni@gmail.com
Date: Wed, 03 May 2017 15:43:25 -0400
In-Reply-To: <CAFitrpRmHtnQuTVPe2o7=CcvisFdxiG1p4uy+qBq0K=tVQ9X4Q@mail.gmail.com>
References: 
	<CAL75PSdAAurv+Rq+22kZLV3rBvcf_WRHxmfKVSXa53-OCtyV1Q@mail.gmail.com>
	 <CAFitrpRmHtnQuTVPe2o7=CcvisFdxiG1p4uy+qBq0K=tVQ9X4Q@mail.gmail.com>
Content-Type: text/plain; charset="UTF-8"
Mime-Version: 1.0
Content-Transfer-Encoding: 7bit
archived-at: Wed, 03 May 2017 19:43:36 -0000

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


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org