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

Reply via email to