qpid-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Rajith Attapattu" <rajit...@gmail.com>
Subject Re: on how to use the qpid java client
Date Thu, 07 Jun 2007 15:39:14 GMT
Hey Rupert,

On 6/7/07, Rupert Smith <rupertlssmith@googlemail.com> 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
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

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
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.


  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message