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 <[email protected]> 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 [email protected] 'cause you'll likely
get quite a good cross-section of the Qpid community looking at it.




---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]

Reply via email to