On 31/07/07, Rajith Attapattu <[EMAIL PROTECTED]> wrote: > > So the low level Qpid API you are talking about is there in the current > code. > However it would be tedious to program at this level with out a good > knowledge of the protocol. > Hence we need a more developer friendly API that is at a slightly higher > level. > This is what we want to promote as an API, and it does contain most of the > methods in the low level API. >
I think that in that case, there is no point in having a seperate Qpid API that is any different to the JMS API. There is the low-level, against the protocol API, tedious to program against, but there for those who might wish to. For example, somebody might conceivably like to hook into the session.ping method notification, to provide feedback to users that an application is still 'live'. Someone else might like to hook into the frame arrival events, to provide a progress indicator, as a large message is received, and so on. I really thought that the low-level API is purely for those who are prepared to learn the protocol and can find some advantage in doing so. Also, Martin points out that having a solid API to call against, that looks like the protocol, and a JMS layer on top of it, would mean that a seperate native implementation could be provided, then it would be trivial to do JMS with a native low-level driver, by wrapping the C implementation as Java native methods. The proposed Qpid API looks too much like JMS to be a usefull seperate concept. I think maybe you came up with the idea of mapping the protocol 1:1 as a first cut, then realised that the end user wants something a little different to call, and are now begining to realise that that thing is JMS, hence are taking your API in that direction, without fully realising yet the fact that JMS is what you really want. For example, there is a direct parallel between the MessageSender and MessageReceiver and Consumer and Publisher in JMS. There is little point in layering JMS on top of the proposed API, to my thinking all it will represent is another layer to slow things down, not to mention the added complication of translating exception hierarchies between the layers. What we have at the moment in the 0-8 client (more or less) is the JMS API, defined as interfaces and the Qpid API defined as interfaces, then a common implementation that implements both sets of interfaces in a single class; not in a layered way, but in a side-by-side way. AMQP specific calls then becomes a 'horizontal' extension of JMS, rather than a sub-layer. 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. Rupert
