Alan Conway wrote:
Not so fast! The python client is living proof that raw AMQP
class/methods ARE quite a usable API.
Absolutely!
Moreover I'd strongly argue that a
clean AMQP class/method layer in each project is an essential part of
converging our implementations and will make development of higher level
features dramatically easier. (C++ is not so hot in this dept. either.)
Having an API layer that maps directly onto the protocol seems like an
absolute no-brainer. It makes everything easier to understand and to
test, giving us equivalent calls that we can write tests to across
implementations and languages.
I'm not arguing that we couldn't/shouldn't build a more friendly,
non-JMS Qpid API but I think todays focus should be on:
- clean AMQP layer in each project
- JMS (for Java) layered over this.
Note that *both* proposed APIs for Java are based on a standard (AMQP or
JMS) so I'm not just making stuff up.
Reasoning from the examples I've been reading and writing, I suspect
that the main difference between the "friendly" API and the more literal
API will be in initialization and cleanup. If possible, a
friendly-but-literal API would be really useful.
Jonathan
