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 support. > > 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 > > > > >
