On 08/06/07, Jonathan Robie <[EMAIL PROTECTED]> wrote:
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.
The arrival of messages from a consumer are essentially events...
which presumably should be handled by some sort of listener... that
concept doesn't occur in the API... how does the python client handle
it?
-- Rob
