qpid-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "John O'Hara" <john.r.oh...@gmail.com>
Subject Re: ActiveMQ can now support AMQP clients.
Date Thu, 26 Oct 2006 10:54:01 GMT

I agree some getting to some kind of compliance testing is necessary.. we'll
probably get there later in 2007.

Also, I wanted to ask you in your capacity as Mentor, in the Apache family
would it be cool to re-use code from ActiveMQ in Qpid where that makes
sense?  A simplistic example would be to re-use selector processing, but I'm
sure there are other synergies.

By the same logic, given that MINA is an Apache project (and a very good
design); wouldn't it make sense to converge on that for IO processing across
both projects?  If MINA is lacking, we could all help make it better.  I
know that Robert has already contributed patches to MINA, and middleware is
a great stress test for a framework like it.

Best regards

On 26/10/06, James Strachan <james.strachan@gmail.com> wrote:
> On 10/26/06, John O'Hara <john.r.ohara@gmail.com> wrote:
> > I'm confused where ActiveMQ is going here.
> >
> > To quote Hiram:
> > "It also means that the AMQP message are in a seperate messaging
> > domain from the JMS messages.  Now that everything is integrated and
> running
> > together we can figure what is the best approach to merging the
> messaging
> > domains."
> >
> > Does this mean that the current implementation is a "cut and
> shunt"?  Where
> > two implementations are parked in the same address space?
> >
> > I'm hoping that the ActiveMQ folk's interest in AMQP is not just a "box
> > ticking" exercise for marketing purposes, and that it's a genuine effort
> to
> > engineer a correct AMQP solution.
> It is. Its one of the reasons why folks from the ActiveMQ community
> keep harping on about wanting a good TCK for AMQP. We've bitter
> experience with TCKs (particularly the J2EE TCK :) but what it does
> provide is a great comfort feeling that providers that pass the TCK
> really are compliant.
> Without a TCK, complex specs take lots of vendor get togethers to make
> them work (as the WS-* folks have found out) and interop between
> providers suffers causing users much pain.
> > The possibilities for damaging an emerging standard here are enormous; I
> > hope that everyone on the mailing list cares about the success of the
> > protocol, and understands the need to work towards good interoperating
> > implementations and the need *NOT* to confuse the market.
> You've confused me again :)  How does ActiveMQ supporting the AMQP
> protocol confuse the market?
> > Have the ActiveMQ folk committed anything to the Qpid code tree
> FWIW Hiram certainly isnt a committer on Qpid nor is the ActiveMQ
> community in general
> > which isn't
> > driven by a desire to import Qpid into ActiveMQ?
> The desire is to share code - partlcularly the low level Qpid framing
> code. We're all Apache folk afterall and projects are meant to work
> together & share code where it makes sense to do so.
> Ideally qpid and ActiveMQ would share a large chunk of ocde for the
> AMQP framing stuff; though right now its hard to do that as qpid is
> not terribly easy to reuse and is based on MINA and ActiveMQ has its
> own transport framework.
> > I most sincerely hope the answer is yes.
> BTW did you see Hiram's patches to the qpid code generation stuff,
> which is pure qpid code and has nothing to do with ActiveMQ at all
> other than making it easier for other projects to reuse Qpid code?
> --
> James
> -------
> http://radio.weblogs.com/0112098/

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message