In another message, I suggest separating out the configuration API from
the messaging API.
In this message, I wonder whether we should consider using either AMQP
1.0 or Java JMS as the model for the new messaging API, rather than
create a third model that nevertheless needs to bridge both Java JMS and
AMQP. If we separate out configuration, I would think either model would
cover everyday messaging operations quite well.
Making the new API more like Java JMS would have the advantage that is
the best known messaging API. Making it more like the AMQP 1.0 model
would allow more direct support of AMQP concepts. Is there an advantage
to having a third programming model that is not based on either?
Jonathan
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:dev-subscr...@qpid.apache.org
