On Mon, 2007-08-20 at 14:41 +0100, Rupert Smith wrote: > > 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?
What you are saying confirms my understanding of your proposal. That is to say that your approach should not be compared nor confronted with the current "API". You approach subsumes the notion of a Qpid messaging API. IF we go for it (I have nothing against) then a potential Qpid API would be implemented on top of it. Am I right? Arnaud
