On 8/22/07, Robert Greig <[EMAIL PROTECTED]> wrote: > > 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 .
As I mentioned on the other thread [JMS extensions] there is no competing API's. The low level Qpid API and the JMS API targets different levels of users. If we clearly document the pros/cons there wan't be any confusion either. 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! The JMS implementation is built on top of the low level API. Hence we maintain only one code base. There shouldn't be any duplication of functionality. As Rob describes It's L4 + abstraction of L1-L3 + a few convenience methods to help the JMS impl and direct users of the low level API. Nothing more. RG >
