On Tue, 2007-07-31 at 09:56 +0100, Rupert Smith wrote: > > 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.
This is a good point and this is one of the reasons why we want to isolate the JMS implementation. The QPID API must be seen as a work in progress. The idea is that once completed it may also be provided by the C++ implementation. So the good reasons for isolating the JMS layer above a QPID API are: - The JMS layer would be marginally impacted by protocol changes - It would be easy to plug the JMS layer on top of different implementations - Even if we don't want to define an AMQP API (I think this would be a mistake of doing that) we would provide a Qpid API that can eventually be adopted and/or impact upon defining JMS 2.0 > 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. I don't think that adding a layer will impact on performances. This should not be an argument in this debate. Arnaud
