First of all, I appreciate that there are several JIRA's opened
identifying the areas that Andrew is hoping to work.
I have gone through the JIRA's and made some comments.
In general I am quite happy about getting the transport code sorted out.
As mentioned in QPID-2811, I have made some improvements to cleanup
the Transport code in the 0-10 path.
Chief among them is the ability to load any transport via reflection
using some simple interfaces and a simple Builder class to construct
our sender and receiver pipes.
I would like to see the following in any future work carried out in the area.
1. Move the additional transport code out of common module. This is a
very important requirement for me as I would like to get rid of the
MINA dependencies.
My goal is to make the clients as light weight as possible with
minimum dependencies in both runtime and compile time.
2. Preserve the ability to load any transport via reflection.
3. Not introduce any dependencies into client or common modules. I
mentioned this specifically as QPID-2818 mentions about OSGi-fication
of the transports on the client side.
This is a big -1 from me, unless this can be achieved via a
separate module without introducing any dependencies into the client
and common modules.
In general I am +1 on making the code simple and easy understand.
I am -1 on making it any more complicated with features that are nice
to have than must have.
Regards,
Rajith
On Fri, Aug 20, 2010 at 10:15 AM, Robert Godfrey
<rob.j.godf...@gmail.com> wrote:
> On 20 August 2010 15:48, Carl Trieloff <cctriel...@redhat.com> wrote:
>>
>> I still think it needs debate,
>>
>> For example, the discussion has been put forward to add in the new API
>> model in Java between JMS and the transports. This is needed. How does
>> that relate to this?
>>
>> This discussing needs to be had a bit more broadly so that all involved in
>> the client can contribute / agree.
>>
>> I would like to see agreement between Rob, Rafi, Rajith, & Andrew for
>> example
>> on this topic.
>>
>> (unless it has happened and I missed it, if I see acks then I'll be happy)
>> Carl.
>>
>>
>
> I want to see the proposal from Andrew before commenting in detail,
> but in general this is going on at a lower layer than the API stuff...
> here we're considering the interface down to the IO layer. At the
> moment this is a bit (no, a *lot*) of a mess, and is completely
> different on the 0-10 codepath and the 0-8/0-9/0-9-1 codepath.
> There's no real reason for the interface down to the transport from
> the different protocol stacks to be different. What I understand
> Andrew to be doing is tidying up where Aidan left off in removing
> dependencies on particular implementations of an IO layer (e.g. MINA)
> from the code, and providing a single interface that can be used by
> the current (and future) protocol versions. As part of this I believe
> he'll be encapsulating the current MINA code behind the interface so
> that it is exposed in a similar way to the IoTransport that was
> written as part of the 0-10 work.
>
> The initial driver for this work is to allow for the running of "InVM"
> tests on the 0-10 codepath in the same way as they are run for 0-8,
> 0-9 and 0-9-1 currently. getting these tests running again needs to
> be a priority for us in terms of proving the Java Broker for 0-10.
>
> The work is really orthogonal to work on adding the new API to the
> Java client and then writing a JMS client library on top of that API.
> While I agree that such an approach could greatly simplify the client
> - it would involve a major re-write which we would definitely want to
> discuss and plan in advance.
>
> I don't think there is any real risk involved in the work Andrew is
> discussing, and it will bring significant benefits in terms of
> allowing us to use alternative IO layers, and unifying the interface
> used underneath 0-10 and the other versions of the protocol.
>
> -- Rob
>
> ---------------------------------------------------------------------
> Apache Qpid - AMQP Messaging Implementation
> Project: http://qpid.apache.org
> Use/Interact: mailto:dev-subscr...@qpid.apache.org
>
>
--
Regards,
Rajith Attapattu
Red Hat
http://rajith.2rlabs.com/
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:dev-subscr...@qpid.apache.org
