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. 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 .
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
