qpid-proton mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gordon Sim <g...@redhat.com>
Subject Re: Using the messenger API to connect to a server without sending or subscribing
Date Mon, 28 Apr 2014 21:21:12 GMT
On 04/23/2014 05:17 PM, Fraser Adams wrote:
> On 23/04/14 16:12, Rafael Schloming wrote:
>> On Wed, Apr 23, 2014 at 10:51 AM, Chris White <Chris.White@uk.ibm.com> wrote:
>>> Our server backend is
>>> built on
>>> the qpid-proton library so ideally we would like our client API to
>>> also be
>>> built using qpid-proton library function.
>>>
>>> As an aside, why is the qpid::messaging alternative API part of qpid
>>> rather than the qpid-proton package?

Another way of looking at that is to ask why the messenger API, as 
opposed to the engine API, *is* in the proton library :-)

>>> Is there a specific reason why it
>>> wasn't built on top of the qpid-proton engine?
>>>
>> The qpid::messaging API actually predates proton. It was originally
>> implemented over the 0-10 version of the protocol. The 1.0 implementation
>> does in fact use the proton engine, however the dependencies make it
>> difficult to separate from the cpp broker.

The reason that they are in the same tree is that there is code in 
common to both the broker and the client. For the 0-10 implementation 
that includes codecs etc. For 1.0 that part is now in the proton library 
that both use. However there are still some other pieces of code used in 
both. It can of course be changed to e.g. have the broker depend on 
libraries that are considered part of the client.

As Alan points out, they can be - and are - packaged separately and 
particularly over AMQP 1.0 the intention very much is that 
qpid::messaging can work well against any broker (or broker like thing). 
I've certainly tested it against several.

[...]
> TBH I'd say the biggest gotcha with qpid::messaging is the boost
> dependency, interaction between boost versions is a regular source of
> pain :-)

With qpid::messaging, though boost is used in the implementation it is 
not exposed through the API (as it was in the older qpid::client API for 
example). What sort of issue do you see?

[...]
> BTW I wouldn't want to come across as favouring proton Messenger or
> qpid::messaging over the other, as I said previously they are peer APIs
> with different advantages and disadvantages,

I'd certainly agree they both have different disadvantages :-) The 
picture faced by users looking for AMQP 1.0 clients is still confusing 
and suboptimal.

> but I'd definitely
> recommend posting queries to users@qpid.apache.org 'cause you'll likely
> get quite a good cross-section of the Qpid community looking at it.




Mime
View raw message