qpid-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andrew Stitcher <astitc...@apache.org>
Subject Re: Alternatives to pn_messenger (QPID Proton C)
Date Wed, 03 May 2017 21:49:13 GMT
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

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.


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

View raw message