On 20/08/07, Arnaud Simon <[EMAIL PROTECTED]> wrote: > > 2. Full mapping of the protocol 1:1 onto the API. > > This is again a debatable criteria. I personally think that some > convenient features like providing support for connection negotiation > would be very helpful. This does not mean that the raw AMQP methods > don't have to be exposed though. >
Already described. The 'conversation' interface, or an equivalent encodes these common synchronous interactions. Exposing the entire AMQP protocol 1:1 does seem like overkill from the point of view of writing applications against, since in the vast majority of cases it is just create connection, create session, send messages (in which case use JMS, or JMS + AMQP extensions). I am making a case for it more from the point of modularizing our implementation, that is, being able to plug clients into comm layer or routing layer or native impl and so on, and keeping open the possibility of alternate implementations of the same set of interfaces. Suppose you implemented the comm layer to an identical (wrt languge) set of interfaces in C++ and Java. Dead easy to call the C++ direct from the Java as a native implementation, supposing that doing so might be more performant. I'm a little unsure but its pretty easy to call C++ from .Net?
