On 6/8/07, Martin Ritchie <[EMAIL PROTECTED]> 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 +1 I agree with both RGs. Refactoring our current Java client is needed. Keeping the JMS extensions will allow for current JMS users to migrate to an AMQP broker and hopefully start to use its features.
[RA] Out of curiosity, how many of your customers use the AMQP features provided by extended JMS? What are the most sought after features? I know that immediate is one such feature. Can you please provide more details? This will help me a lot in shaping some of my current work. I have no objection to an AMQP API in the client code base but as others
have said investing time just now in making it a public API when the spec is in such a state of change isn't warranted, but when the spec is more settled then we can reevaluate .
[RA] As part of the re-factoring there is going to be a visible API. And as the spec changes we have to do the modifications whether we expose the API or not. So I don't buy the argument about the time being invested. Also anybody using the API will do so with the explicit understanding that this will change. I think I repeated this sentence for the 100th time :) The JMS extensions would ideally be picked up (or some set of exposed
AMQP functionality) by the AMQP WG and provided in a AMQP->JMS mapping document as RGreig said. -- Martin > > > > 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
