Hi, My understanding is that Andrew is trying to make the I/O layer more generic in the first instance and rationalize the path from the wire to the protocol specific code in the same way for all the available versions of amqp. As soon as that is done, we can swap out Mina from both sides should other frameworks be better suitable for Qpid and also handle the future versions in a unified manner.
Cheers, Sorin On Fri, Aug 20, 2010 at 1:47 PM, Carl Trieloff <cctriel...@redhat.com> wrote: > On 08/20/2010 05:45 AM, Andrew Kennedy wrote: >> >> Hi. >> >> I'm currently looking at the 0-10 transport layer in more detail, and >> want to add a (currently) MINA based VM mechanism to the existing >> socket based one, and eventually I envisage pluggable OSGi modules >> that implement Netty or Grizzly transports for both the client and the >> broker, using any AMQP protocol. >> > > My understanding we where trying to get rid of MINA in the Java client, > this implies going the other way. I believe this need to be debated, as I > think we want to get rid of the mina dependency which is preventing > some of the needed JMS cleanup. Rob, Rafi, Rajith... please comment... > > Carl. > > > > --------------------------------------------------------------------- > Apache Qpid - AMQP Messaging Implementation > Project: http://qpid.apache.org > Use/Interact: mailto:dev-subscr...@qpid.apache.org > > --------------------------------------------------------------------- Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org