qpid-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alan Conway <acon...@redhat.com>
Subject Re: on how to use the qpid java client
Date Wed, 06 Jun 2007 13:53:06 GMT
On Mon, 2007-06-04 at 15:19 +0100, Rupert Smith wrote:
> On 04/06/07, Tomas Restrepo <tomas.restrepo@devdeo.com> wrote:
> 
> > I agree this is a valid question, but at least from my point of view,
> > uniformity of the API isn't such a big deal, for this kind of project in
> > particular. That said, if the API were to be that AMQP-compatible API,
> > which
> > is certainly fairly low level, then by that virtue alone the API would be
> > fairly similar across implementations, simply because it would resemble
> > the
> > AMQP class/method model fairly closely. I believe we'd likely still have
> > some differences for things async operations (which definitely have
> > different conventions across languages), but that wouldn't be that bad.
> >
> 
> 
> I can be brought round to this point of view. As you rightly point out the
> API is going to look like the protocol anyway. Also Robert Greigs post about
> developers using the appropriate API for their language and that being the
> one to implement, clarifies what is more important.
> 
> Rupert

+1 to this: establishing a similar "raw AMQP" API layer in each project
based on the AMQP XML and building on top of that. I say "similar" not
"uniform": the XML is the rosetta stone, each language should map the
XML in the way best suited to that language. However it should be
possible (although not necessarily promoted to users) to write a client
on _only_ this API. Higher level APIs (JMS, the current C++ client etc.)
would be layered on top.

This solves a lot of problems: XML provides common terms that will be
used in class & method names, this layer can (should) be code generated
as far as possible so it will automatically extend to cover new protocol
features, and it will be easier for developers to work across projects -
they know the concepts, just need to learn the local mapping rules.

This API is low level and tied to protocol changes, so it's not suitable
for some customers: JMS, NMS and other high level APIs should be based
on what users in that language are used to.

Python is the best (only?) example so far of a clean "raw AMQP" client.
I've been wanting to do a consistent "raw AMQP" underpinning for C++ for
some time now. Is this something to consider for the current Java client
work?

Cheers,
Alan.




Mime
View raw message