On 31/07/07, Arnaud Simon <[EMAIL PROTECTED]> wrote: > On Tue, 2007-07-31 at 10:45 +0100, Robert Greig wrote: > > On 31/07/07, Rupert Smith <[EMAIL PROTECTED]> wrote: > > > > > I don't see any point in promoting a 'developer friendly' API in Java that > > > is not JMS. The developer friendly messaging API for java is JMS. > > > > I completely agree. > > > > RG > > I don't agree as this interface should be used for exposing specific > AMQP features.
Who are we to decide what specific features of AMQP will be useful to expose. Either we create a low level API that exposes AMQP or we don't? I thought that we had decided that a low level API was indeed useful. > The real debate is whether we wrap the AMQP classes > around a higher level API. I personally think that we should as there is > no notion of AMQP API and we should not introduce one. The lack of a standard AMQP API should not be a barrier to Qpid creating one if you really want to call it a Qpid API we can discuss nomenclature once we know what the content is going to be. If we don't start to work out what the API is who is? From what I understand the AMQP-WG are busy working on the core protocol and not standardising any API. This gives us the opportunity to provide feedback to the group with a usable and tested API. If they decide that it is not the direction they want to take that doesn't make our work any less valid but if they do take it then we have an instantly compliant client. > So, we are thinking about defining a QPID QPI that may eventually impact upon > the > JMS one. The Qpid API should be impacting an AMQP API which in turn should be impacting any JMS API changes. I don't think that a single vendor's(Qpid) implementation would be strong enough to change JMS but a new messaging standard (AMQP) would have the weight to make such changes -- Martin Ritchie
