On Tue, 2007-07-31 at 14:06 +0100, Rupert Smith wrote: > > > 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.
I understand your concerns but I would say that whatever interface we provide will have to be based on a lower level API. So, I don't think that it will be such a work exposing such an interface if we eventually make the decision and, as I said, the current API would become part of the JMS implementation. > 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. I agree that we need to work on it but in the same time we need to make progress. This is why I am suggesting to keep what we have out of this loop and to consider it (if required) as part of the JMS implementation. We should not try to kill two birds with one stone. Arnaud
