Hi, I think that all agree about having a Qpid API. Now we may not agree about the granularity level of such an API. I like to make several points clear so we all speak about the same thing: - We have introduced a common communication layer that will be used by both broker and client implementations. I think that we all agree on that layer. - The aim was to isolate the JMS layer from this communication layer for three main reasons: for shielding the JMS layer form specification changes, for simplifying concurrent development efforts and for achieving a certain level of plugability of our JMS layer. - On the client side this communication layer has been exposed to the JMS layer through what we call a Qpid API. This is the point where we don't agree and the debate is about the granularity of this API.
This API is currently a convenient way of isolating those three layers and is NOT fixed. We however need a certain level of stability if we want to eventually deliver a 1.1 client. So, the approach we went for was to define a simple API that we would refine when developing the 1.1 client code base. I think that we all agree that this is a good thing to expose a specific QPID API even if THIS API does not have to be exposed as if. Another API can be exposed on top of the communication layer and the current interface can be kept private and only seen as a convenient way of implementing JMS. So, all what I am saying is that we really need this debate and I appreciate very much Rupert and Martin concerns about the current Qpid API. But, this API is not finalized and can be replaced by another one that is closer to the protocol (the current one would therefore be seen as a convenient layer on top of the communication layer). Arnaud
