On Wed, 2014-04-23 at 17:17 +0100, Fraser Adams wrote:
> On 23/04/14 16:12, Rafael Schloming wrote:
> > On Wed, Apr 23, 2014 at 10:51 AM, Chris White1 
> > <chris.wh...@uk.ibm.com>wrote:
> >
> >> Hi all
> >>
> >> Thanks for the informative and very helpful responses.
> >>
> >> We did look at qpid:Messaging but this seems to be separate from the
> >> qpid-proton library, and there is a concern that the is no Java API and
> >> some of the function we require is missing. 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? 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.
> >
> I think that there's a good argument for making a lot of core Qpid 
> behaviour a lot more modular so that qpid::messaging can be more easily 
> packaged separately from the broker. I've cross-posted to the user list, 
> as I said earlier the main Qpid user list has quite a wide audience.

qpid::messaging can be and is packaged separately from the broker, e.g.
on fedora it is packaged as qpid-cpp-client and qpid-cpp-client-devel.
It will use the qpid-proton package if installed to provide AMQP1.0

> To be fair the reason for the coupling that exists is just how things 
> ended up getting developed and there is work being put in to make Qpid 
> as a whole much more modular. Indeed arguably that's why Proton emerged 
> as a separate sub-project, as has the dispatch router and the new AMQP 
> 1.0 JMS client. There's a lot more that could likely be done over time, 
> one of which is likely greater decoupling of qpid::messaging.
> Indeed a lot of the broker features for both the C++ and Java broker 
> could potentially be fairly generically used in more general AMQP 1.0 
> containers, TBH there hasn't been much discussion on that sort of thing 
> yet, but I suspect refactoring could yield some reusable components.
> TBH I'd say the biggest gotcha with qpid::messaging is the boost 
> dependency, interaction between boost versions is a regular source of 
> pain :-) a key part of Proton has been to aggressively minimise 
> dependencies, which is often a big plus.
> BTW Re "there is a concern that the is no Java API" there is, it's 
> called JMS :-) so the idea behind qpid::messaging is that is provides a 
> pretty close C++ approximation to the JMS API, so basically the Java 
> equivalent of the qpid::messaging API is the Qpid JMS client, if you see 
> what I mean.
> You should take a look through http://qpid.apache.org/
> 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, but I'd definitely 
> recommend posting queries to us...@qpid.apache.org 'cause you'll likely 
> get quite a good cross-section of the Qpid community looking at it.
> Best regards,
> Frase

Reply via email to