Just to add a few thoughts... In the AMQP working group we have been talking about some sort of standardisation of an AMQP API. If such a standardisation takes place I would expect each Qpid client library to implement to that standard. Before such a standardisation we obviously running a risk by defining our own API that it is not substancially the same as that agreed by the AMQP working group - then we would be having to support three separate APIs :-(
My view remains that we should build an internal API based on AMQP in terms of which we write our JMS implementation. I would not be encouraging our users to use that "AMQP" API until such time as AMQP has sufficiently stabilized and established API guidlines. -- Rob On 07/06/07, Jonathan Robie <[EMAIL PROTECTED]> wrote:
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
