---------- Forwarded message ---------- From: Rupert Smith <[EMAIL PROTECTED]> Date: 20-Aug-2007 15:09 Subject: Re: [Java] Message API design notes To: [EMAIL PROTECTED]
But what I am proposing has already been compared with that proposal, because Rajith said that his proposal was 1:1 protocol derived, and fully took account of previous list discussions. It isn't either, so I am setting the record straight, and representing my ideas again. Yes, you are right, the aims of the two proposals are a bit different. Yes, There could well be a Qpid API on top of this stuff. I do think that the 'conversation' class idea covers the majority of what is needed. Also, I am more in favour of the AMQP enhanced features being a horizontal extension of JMS for Java, rather than JMS being implemented on top of a seperate Qpid API. I think it is important that the 0-10 client implement the existing horizontal extensions, found in org.apache.qpid.jms, providing back compatability for code written against those extended interfaces. So if you want a 'chunking' message API, just add it onto what is already in org.apache.qpid.jms. It just seems a little unnecessary to me to have to have an exception listener: *onException<http://people.apache.org/%7Erajith/qpid_docs/client_api/org/apache/qpidity/client/ExceptionListener.html#onException%28org.apache.qpidity.QpidException%29> *(org.apache.qpidity.QpidException exception) That is going to have to translate its exception into a JMSException, not to mention translating Qpid messages into JMS messages etc. Makes sense to me to have a seperate Qpid API for the other languages, given that they are not supposed to re-implement JMS. On 20/08/07, Arnaud Simon <[EMAIL PROTECTED]> wrote: > > 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 > >
