Michael Arnoldus wrote:
From my point of view it's very cool to stop the standards at the wire level protocol. That means several java API's can coexist, and people can use several brokers. Freedom increases.
I very much share this view. The API is in my view one of the distinguishing features of a client; let people innovate.
I think it would be premature to start trying to standardise. The java world is not (in my opinion) looking for a standardised messaging API; that role is currently fulfilled by JMS.
For Qpid we know we want a fully compliant JMS client. Applications using that API can be reasonably confident that their code is isolated from the details of any specific implementation.
We should be able to offer users of that client different features not directly exposed through the JMS API. E.g. synchronous v. asynchronous publication perhaps, different prefetch/flow control strategies, different ways of handling large messages, different ways of binding queues to exchanges, utilising the mandatory flag and alternate exchanges etc. These are all things that would be valuable to applications and shouldn't really require them to change the way they write their applications.
It is also valuable to have a usable library that works more directly with AMQP commands. We want this for writing the JMS client anyway, making it usable on its own allows others to take it and pursue alternative ideas as well. (For example I think it could be interesting to have a more tuple-space like API available that uses AMQP underneath).
It seems to me there is a lot of necessary and valuable work we can do within Qpid to make our software better both in the set of features it exposes and the manner it exposes them. That work is in my view more worthwhile than trying to standardise our APIs.
