On 6/7/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 :-)
[RA] If you look at the new refactored code you can identify two layers. The interfaces defined in o.a.q.newclient.amqp and the interfaces defined in o.a.q.api package. These offer different levels of flexibility and convinience. It looks like you are talking about something in between? (I stand to be corrected) Where would u position your public API? Another thing is we need to maintain these layers for our own sanity (call them internal APIs if u will). So people who are looking for more flexibility can tap into any of these layers. We don't have to promote these as API's, but lets document them properly and identify them as possible extention or leverage points. (of course people will do so with explicit understanding that these may change more frequently than an API). thoughts?? Rajith -- 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 > > >
