On Fri, 2007-06-08 at 08:25 +0100, Martin Ritchie wrote: > On 07/06/07, Robert Godfrey <[EMAIL PROTECTED]> wrote: > > I know this was aimed at Robert and not me... but... > > > > > How about we continue to use the so called extended JMS API. > > > We can build that on top of the AMQP API. There will be an additonal layer > > > that may look like an API (but we will not promote that). > > > (We all agree that current code needs refactoring, so there is no issue > > > there) > > > > +1 We refactor our current client to use an AMQP level API. We keep > > at least the current level of expressivity for our JMS client. We aim > > to build extensions to JMS to allow end users to reach all sensible > > AMQP functionality. > > > > I'm comfortable with an AMQP API... but I think we need to have a > > proper discussion on what a *public* API would look like... it should > > probably be a little more friendly than raw AMQP > > class/method/arguments :-) > > > > -- Rob
Not so fast! The python client is living proof that raw AMQP class/methods ARE quite a usable API. Moreover I'd strongly argue that a clean AMQP class/method layer in each project is an essential part of converging our implementations and will make development of higher level features dramatically easier. (C++ is not so hot in this dept. either.) I'm not arguing that we couldn't/shouldn't build a more friendly, non-JMS Qpid API but I think todays focus should be on: - clean AMQP layer in each project - JMS (for Java) layered over this. Note that *both* proposed APIs for Java are based on a standard (AMQP or JMS) so I'm not just making stuff up. I *suspect* that an AMQP API will serve the needs of most anti-JMS customers, or at least be enough for them to get started while we figure out what (if any) other higher-level API features we want. If not the AMQP layer will make it *much* easier to implement and maintain multiple "personality" layers on top. Cheers, Alan.
