Alan, We already have a low level AMQP protocol API. It's exactly a 1-1 map of the protocol level classes. Similar to Python u can do message.ok , message.transfer , connection.secure..etc
Regards, Rajith. On 6/6/07, Alan Conway <[EMAIL PROTECTED]> wrote:
On Mon, 2007-06-04 at 15:19 +0100, Rupert Smith wrote: > On 04/06/07, Tomas Restrepo <[EMAIL PROTECTED]> 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.
