Rupert Smith wrote:
Do we need/want/have the will/time to expose a common Qpid AMQ API
accross
all clients? If we want uniformity, and some choices and changes are
currently being made as to what the .Net API will look like, it would be
prudent to reach a concensus first, or else we will just end up with two
more non-uniform APIs.
I absolutely agree that the goal should be to have consistent APIs
across languages, including Java. Obviously, we also need really good
support for JMS, in addition to the native AMQ API.
Also, I could probably take the
AMQSession class, chop into two pieces, and I would end up with a JMS API
and an AMQP API more cleanly separated. I feel there is value in adapting
the old into the new, to re-use existing code as much as possible, to
make
sure some of the 'clever bits' don't get forgotten, and also to ease
refactoring of code, tests for example, that have been written to the AMQ
API rather than JMS, to be refactored along at the same time.
Makes sense to me - the fewer code bases to deal with the better ....
Do note that I'm not saying that the design of the new client API is
wrong.
I had a quick look at these examples, and it all seems right enough to
me.
I agree.
Jonathan
