Alan has a very good point or two or three. Perhaps this is a juncture where laying out a clear set of use cases for the API layer is appropriate. From this a more grounded technical discussion of the best approach can be had. Can the JMS APIs be extended to effectively cover the use cases? Would extending the JMS API result in unacceptable inefficiency during execution, unacceptable complexity in the API, or an unacceptable/unworkable level of abstraction between API and function? Do developers need/want a new messaging API? Can they be convinced to use it?
>From a documentation stand point both approaches can be handled. An extended JMS API makes for less pages, but if the API gets to convoluted it makes for a mess. The separate Qpid API means more pages but a cleaner separation. > -----Original Message----- > From: Alan Conway [mailto:[EMAIL PROTECTED] > Sent: Monday, September 18, 2006 11:21 AM > To: [email protected] > Subject: Re: QPID/HermesJMS > > It seems to me that regardless what happens there *will* be a JMS API > and there *will* be a Qpid API. The JMS layer has to call on something! > > The question is whether there is real value in documenting multiple > ways for users to do the same thing in Qpid. I don't know the answer, > but I'd like to see some concrete examples of where people feel the JMS > API is inadequate, inefficient or just repulsive, and how we could do > such a better job in Qpid that people would find it worth their while to > learn a new API and write code they'll never be able to port to another > JMS implementation. I'm not saying it can't be the case! I'm just > curious about the innovations people have in mind for Qpid's API. > > Cheers, > Alan. > > On Mon, 2006-09-18 at 11:06 +0100, Gordon Sim wrote: > > Steven Shaw wrote: > > > On 15/09/06, Robert Greig <[EMAIL PROTECTED]> wrote: > > >> I think we agree that we need to expose functionality that goes > beyond > > >> JMS. The question is whether we can do this though extension points > to > > >> JMS or whether we need a separate API. > > > > > > Perhaps both. > > > > I agree with this view. The different ways of exposing functionality > > need not be mutually exclusive. > > > > Support at the 'protocol' level makes it easier for the full flexibility > > of AMQP to be exploited in perhaps unanticipated ways. > > > > As an example, pulled out the air, imagine a particular use case wants > > to set up a single queue with several bindings. Rather that trying to > > anticipate all these sorts of usage patterns from the start a more > > directly exposed protocol layer would make these easy to compose from > > the protocols own building blocks. > > > > However JMS is clearly the first choice for the vast majority of > > messaging based systems written in java, so allowing these system to > > exploit the protocol through API extensions or configurable semantics or > > mappings is also going to be important.
