---------- Forwarded message ---------- From: Rupert Smith <[EMAIL PROTECTED]> Date: 20-Aug-2007 15:54 Subject: Re: [Java] Message API design notes To: [EMAIL PROTECTED]
On 20/08/07, Arnaud Simon <[EMAIL PROTECTED]> wrote: > > So today the current API could be seen as part of the JMS implementation > i.e. some useful methods for interfacing with the common layer. > Back on the JMS extensions, I haven't implemented them yet. The idea is > to have first the JMS tck passing then to provide support for the JMS > extensions. What do you think? Does that make sense? > It makes some sense, totally fine with things being done in stages. I just think that this proposed API does not actually look very useful, as a 'useful' layer to put between the JMS implementation and the comm layer. It looks to me like it would be better to be putting the JMS layer straight onto to comm layer, without this 'strange cousin' of JMS getting in the way; as I've said before it just seems like an extra layer for no good reason (other than perhaps, creating work for people?). Be great if the JMS layer can implements a ProtocolClient delegate, and call a ProtocolBroker invoker, and be capable of being aware of every event in the protocol if it needs to. That is, expose the whole protocol through a interface only API, and put the JMS on top of it, handling and calling just what it needs to. Also, as far as a Qpid API is concerned, there was general agreement some months ago, when this was all debated before, that such an API should 'look like the protocol'.
