On 07/06/07, Jonathan Robie <[EMAIL PROTECTED]> wrote:
These are the users who have listened to our claims that AMQ is platform-independent and language-independent.
Obviously, JMS is the current mainstream solution - we need to support JMS, and support it well. Obviously, if we have two Java APIs, they should probably be two APIs to the same code base.
What does that imply about those APIs in terms of features and interoperability?
But if our message is that AMQP is just a better way of implementing JMS, we lose those people.
I don't think anyone has suggested that? The crux of the matter is how to expose AMQP-specific functionality in Java where JMS is the predominant MoM API.
If people only care about JMS, then we should drop our C++, Python, and Ruby language bindings, because they are irrelevant.
I don't see how this follows at all? What about people who want to use Java and C++ and interop using AMQP?
I'm talking to major customers who simply don't care if the API is JMS, but do care about the ability to use scripting languages together with conventional languages, and want a simple, consistent API across languages. Shouldn't we give them that?
I think it depends what the effort of doing that is. As I have said I think it would be a big mistake to go down the route of having two APIs where one is less powerful. Do people complain about JDBC? RG
