Martin Ritchie wrote:
I think that not allowing AMQP functionality via an extended JMS API
is a mistake. Going down this route would, IMHO, detriment AMQP.
I also think that not allowing AMQP functionality via a pure AMQ API is
a mistake.
Isn't the obvious solution to have two APIs?
And if someone has learned the AMQP model, and wants to work with AMQP,
why should they have to learn JMS first?
> [RA] I'd rather like to say that JMS support is a nice value
addition than
> the main goal of Qpid java.
I find that a staggering statement. To help me understand can you
please explain what you think the main goal of Qpid Java is?
I have to agree... the Qpid Java clients first goal should be JMS
support otherwise it is just another incompatible messaging product
requiring large scale re-engineering of existing code.
This reminds me of the old arguments in the XML community about whether
our standards should be designed to support documents or data. If XML
didn't have really good support for both, it would not have succeeded
the way it has.
Of course support for JMS is crucially important. But if that's all we
do, I think we've missed a rare opportunity to dramatically simplify
interoperable computing across languages and platforms.
If all we care about is JMS, let's stop spending time thinking about
anything else. But of course, the write answer is to create a really
good hub that can be used for JMS and other existing and future systems,
but also can be used quite nicely all by itself. In standard computer
science terms, let's keep these systems orthogonal, but make sure they
work very well together.
Jonathan
