On 31/07/07, Arnaud Simon <[EMAIL PROTECTED]> wrote: > > 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
I was under the impression that the proposed API was the proposed Qpid API to be exposed as our published API. So thanks for explaining that it is of a temporary nature. Points above accepted, but if you are going to change this API, and it is what the JMS layer is built on top of, then it follows that the JMS layer will have to change, as it changes. So the isolation of the JMS layer from change, is negated by the argument that the proposed API is temporary. One of two things will happen, either what was proposed as a makeshift solution will become permanent, or the API and therefore the JMS layer will change too. I think that, especially if this API is implemented in all languages, the first option is far more likely to be followed; it will be too much effort to change it and attrition will set in. So how about working out what the low-level API will be now? The thing about APIs is, you rarely get more than one shot at designing them, and designing a really good one is not easy. Lets make damn sure we get it right. On the other hand, if there is an absence of time and will to work out a low-level API to expose now. You may as well put the JMS layer right on top of the comm layer anyway, seeing as it is only going to have to change. Right now, I'm looking at the API and thinking that its more of a 'nuisance' layer to implement JMS on top of (particularly translating exceptions, ugh), than a 'convenience' layer. On the other hand, the comm layer is intuitive and looks as though it will stand up to usage accross different protocol versions. You pass in frames at the bottom and get method calls out the top, or pass in method calls at the top and get frames out the bottom. I think I would be very tempted to focus on the Invoker and Delegate interfaces, as a good starting point for fleshing out a low-level API. Also, I think that the requirement to isolate against change is a bit of a red herring. The protocol is not evolving so rapidly that we cannot keep up, and when the protocol does change, it could be in semantically subtle ways that we cannot isolate ourselves from anyway. Best way to isolate against change is to use solid bottom up OO design, imho. Then at least you always have good code to re-use. Rupert
