Rajith, To be fair, the protocol is changing so much for 0.10 that there will be correspondingly large changes in the code, so I hope I haven't been to critical of your efforts, after all, its your hard work too.
I think, we will make sure we carry forward the desired bahaviour of the client, in terms of tests through the JMS API. I think you haven't implemented the JMS part for the new client yet? So the existing JMS client on trunk should possibly still be working. Once M2 is out of the way we can evolve forward, onto the new AMQ layer, with our regression tests. Please tell us about the design of the new client? Lets go back up to the top of this thread and engage in the original discussion about the API of the new client. I must say that, I am intrigued by the idea of presenting the protocol classes and methods in raw form as an API. It will be like having the protocol available to code directly against. I can see some advantages of this approach. For example, it looks like you have defined the protocol as a set of interfaces in the org.apache.qpid.nclient.amqp package. If we were, for example, to have an in-VM transport for clients that attach directly to a broker, it would seem to me that the broker could provide an implementation of these interfaces that is called into directly. Rupert
