qpid-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alan Conway <acon...@redhat.com>
Subject Re: Alternatives to pn_messenger (QPID Proton C)
Date Thu, 04 May 2017 00:08:44 GMT
On Wed, 2017-05-03 at 17:49 -0400, Andrew Stitcher 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.

I agree with Andrew that the C++ API is easier to use because of the
features of C++. However if you want to work in C, the proactor API is
(in my *very* biased opinion) not significantly harder to use than
pn_messanger or pn_reactor, and provides much more user control and
implementation flexibility.

The proactor API has not been widely used yet, but is (informally)
finalized and will soon be released. We have just moved a significant C
project (http://qpid.apache.org/components/dispatch-router/index.html)
onto the proactor APIs with a good reduction in code and no obvious
problems (yet). Dispatch was not using pn_messenger so I can't comment
on migrating from messenger, but I will be happy to answer any
questions as I'm keen that the proactor succeed as a replacement for

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

View raw message