To me, a very important set of users is:
5. people who do care about the API, and want a simple, powerful API
with no platform-specific dependencies on .Net or Java, and want to be
able to use essentially the same API across languages (taking into
account differences that can't easily be ironed out across languages).
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.
But if our message is that AMQP is just a better way of implementing
JMS, we lose those people. If people only care about JMS, then we should
drop our C++, Python, and Ruby language bindings, because they are
irrelevant. 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?
Jonathan
Robert Greig wrote:
The question is whether that fits into an overall strategy for all our
users. As I see it we have different users with different
requirements:
1) people who have an existing codebase written in terms of JMS
(including e.g. Spring JMS higher leve stuff) and want to migrate to
Qpid with as few changes as possible
2) people who are starting from no code but their corporate policy
dictates that messaging should use JMS (I know at least one large
corporation like that :-)) and the apps are simple so will just use
standard JMS
3) people who have a codebase written in terms of JMS but are
interested in some of the capabilities that are being designed into
AMQP
4) people who have no codebase and don't care about the API but want
to exploit the features of AMQP
Will the people in (4) walk away if they have to use a JMS-like API? I
understand they will walk away if the API doesn't give them the
flexibility or performance they require but from your post you imply
that the mere fact it is a JMS API is a deal breaker.
