Robert, You highlight a good point. I think it was mistake for us to deviate from the spec to support JMS. However I think we tried to make that configurable via the stritct AMQP flag. Apparently we seem to have fallen short there. The other major issue if the access ticket thing, but If I remember Rabbit had someway of disabling this right? But as Carl points out do we have time and resources to do this? On other hand if you think you can do it without much effort then by all means you can do that for M2.1.
Regards, Rajith On Jan 11, 2008 9:37 AM, Robert Godfrey <[EMAIL PROTECTED]> wrote: > 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 > > > > > > > -- Regards, Rajith Attapattu Red Hat blog: http://rajith.2rlabs.com/
