On 22/08/07, Robert Godfrey <[EMAIL PROTECTED]> wrote: > I do not particularly see the need for an API which is neither JMS that > doesn't look exactly like the model layers of AMQP [that is the API need not > expose all the 0-10 features for connection establishment, session > maintenance etc... those are functions of the client library and shouldn't > be exposed to the application programmer - For those familiar with AMQP 0-10 > I think the API should provide hooks into all of Layer 4... with > abstractions for the lower layers].
Yes, I agree and would go further. I think it is positively detrimental to Qpid to have two "competing" APIs . It is confusing to potential users - which API to choose? Remember that a large proportion of our target userbase is an "average" enterprise developer where messaging may only be a small part of the application. It is also detrimental to the overall Qpid effort since it is more code to support and document, duplicating functionality in our extended JMS API. Don't forget the opportunity cost! RG
