Interoperability must be a priority for us. It was definitely a mistake for us (Qpid) to change the spec file that we were working off in ways which made it incompatible with other 0-8 implementations, even if the intent was good (we were tracking emerging changes to the spec).
What I have done in the 0-9 implementation of the Java is to add to the spec in ways which do not break compatibility with generic AMQP compliant 0-9 clients. My view is that we should make it a priority to get Qpid interoperating with the other AMQP implementations, and that therefore strict AMQP compliance is important. I realise that many of us want to move to AMQP 0-10 which is about to be released publicly; however given the products on the market which already use 0-8 or 0-9 I think it would be advantageous to try to provide comprehensive support for this version. Also as Qpid has the widest language choice of client implementations I think it helps everybody if we make available compliant 0-8/0-9 versions of these. Now, in order for our Java client to implement JMS we do need to put in extensions over base AMQP; and if you want to use JMS messaging using AMQP, then Qpid will be the only choice at the moment - until we can get equivalent functionality incorporated into the AMQP spec. As Michael makes clear below - one (possibly compelling) factor influencing people to choose to use an AMQP broker over some other vendor's messaging product is the fact that alternative implementations exist. Therefore we should look to co-operate as well as compete; and in particular work to make sure all AMQP products can exchange messages seamlessly. -- Rob On 11/01/2008, Michael Arnoldus <[EMAIL PROTECTED]> wrote: > Hi Robert, > > On Jan 10, 2008, at 17:14 , Robert Greig wrote: > > > > The only reason for the deviation from the AMQP spec was that the > > official 0-8 spec had limitations that meant we could not achieve full > > JMS compliance without some changes. We had other users for whom full > > JMS compliance was critical. > > And I can see why that would make sense from a java perspective. > However that actively discouraged us in trying out QPID as a broker. > > > > > > >> Also - interesting discussion about performance - I'd be interested > >> in > >> better and less biased comparisons, while I'm still aware that msg/ > >> sec > >> and latency is not the only interesting kind of performance in a > >> product like this. > > > > What are your performance requirements? What client implementations do > > you need? Are you interested in road testing Qpid? Our recent M2 > > release incorporates a huge number of changes and improvements. > > Currently my primary performance requirements are stability, ease of > installation and use, scalability and support. If you win in those > areas, I really don't care if I need to buy machines with 4 times as > many cores to achieve the same performance. If I have scalability, > hardware is VERY cheap!!! Using my developers time on stuff that > doesn't work, are difficult to use or to build are far more expensive. > > Thanks for your offer on road testing, which I have to decline. We're > fairly busy at the moment, and Rabbit actually works for us right now. > However it is very important for me in my choice of AMQP that several > implementations do exist - and I do find QPID interesting and will > definitely try it out in the future. > > Michael > > >
