Aidan Skinner wrote:
The Java client uses JMS for this to an extent, but we still need a
way of exposing AMQP specific things in ways that are as version
independent as possible (such as the mandatory flag).
I can see that there is value in reaching out to developers who have JMS
code or who
wish to retain JMS capability, *please* don't hobble Java users who want
the full-fat
qpid experience by making everything fit with JMS. Case in point: the
Java client for
postgres is annoyingly limited as soon as you want to receive async
notifications and
so on. I would much prefer the most efficient and direct mapping to
AMQP facilities
possible in each language, and an adapter to legacy APIs.
Sun's failure to consider interoperability with other language
environments continues
to haunt it. :-( There is much to learn from ActiveMQ interoperability.
There are lots of JMS implementations. My own interest in AMQP is
largely driven
by it NOT being JMS - so there is a chance that my C#, Python and C++ code
can be first class citizens. Clearly other people will have different
priorities. I'm
interested to know why a (happy) JMS user would be interested in AMQP
though:
JMS has things which are handy in Java but will be awkward in a
heterogeneous
system.
Perhaps something to consider is trying to make the C/C++ client as
lightweight as
possible and having a reference SWIG wrapper. In this case I would
ideally look
for the client to be 'passive' and allow the host to do raw connection
establishment
and raw IO so it acts as a protocol engine and avoid issues of event
loop integration
and so on.
James
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:dev-subscr...@qpid.apache.org
