Hey Rupert, On 6/7/07, Rupert Smith <[EMAIL PROTECTED]> wrote:
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.
[RA] thanks. My goal is to accomadate these changes with minimum impact to the overall architecture. Ex. The new execution sub layer, the session layer and the channel/session relationsjip etc. However when we change the protocol classes like Message or Session will result in changes to the API. These changes are likely to happen until the protocol stabilizers a bit. 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.
[RA] I would love if you guys also participate in evolving the Qpid client and the JMS layer. I will be comming for the f2f in Aug and I hope u and martin have confirmed too. Lets put our heads to gether and implement/improve the JMS layer. Until then I will slowly start building the JMS layer on top of the Qpid client. 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.
[RA] Thats the idea. Have u had a chance to look at the design doc on the wiki? Also did u get a chance to review the code? Is there any additional informaiton required by u? I am more than happy to improve the documentation. I also tried my best to put comments in the code itself. 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.
[RA] Exactly. I have spoken about this with Robert too. We can improve this API to build the lower levels of the broker too. Rupert
