On Fri, Aug 20, 2010 at 11:37 AM, Andrew Kennedy <andrewinternatio...@gmail.com> wrote: > On 20 August 2010 16:16, Rajith Attapattu <rajit...@gmail.com> wrote: >> 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. > > +1 Although I'm not sure we yet have a good way of managing external > modules that have dependencies. I am still thinking about the best way > to do this. > >> 2. Preserve the ability to load any transport via reflection. > > +1 On the client, I don't intend to remove this. At first I thought > about doing a similar thing to the broker with OSGi, but I don't think > this is really feasible yet. The reflection mechanism (class.forName() > basically) would still be used, with a system property to decide what > transport to be used, and the external module supplied on the > classpath as a .jar file. > >> 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. > > Heh, see my quick edit - i realised this might be misconstrued as soon > as I hit submit on the comment, so I edited it to add '(on the > broker)' which I hoped would make things clearer... > >> 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. > > Agreed, and I will straighten out the documentation I'm working on and > add the relevant parts to some of the JIRAs so people have a better > idea what I'm trying to accomplish, but I believe we're on the same > page here...
Indeed we are. Thank you sir for your explanation. Looking forward to the doc and will pitch in as time permits. Rajith > Andrew. > -- > -- andrew d kennedy ? edinburgh : +44 7941 197 134 ; > > --------------------------------------------------------------------- > 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
