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
This way a) People who use JMS (existing and who wants to use JMS in the future) can leverage AMQP features if they want. b) People who are not worried about JMS can use the AMQP API to do what they want. (Ex. other apche projects ..etc) c) This way the AMQP API is not going to make the JMS API look less powefull as stated. Regards, Rajith On 6/7/07, Robert Greig <[EMAIL PROTECTED]> wrote: > > On 07/06/07, Robert Godfrey <[EMAIL PROTECTED]> wrote: > > > In the AMQP working group we have been talking about some sort of > > standardisation of an AMQP API. If such a standardisation takes place > > I would expect each Qpid client library to implement to that standard. > > Before such a standardisation we obviously running a risk by defining > > our own API that it is not substancially the same as that agreed by > > the AMQP working group - then we would be having to support three > > separate APIs :-( > > Yes, two APIs is more than enough work in my opinion and three would > be an API too far. > > > My view remains that we should build an internal API based on AMQP in > > terms of which we write our JMS implementation. I would not be > > encouraging our users to use that "AMQP" API until such time as AMQP > > has sufficiently stabilized and established API guidlines. > > I agree with this. > > What is your view on how any AMQP-specific features should be exposed > to end users (in Java)? > > RG >
