I agree, compatibility has already been broken between minor 3.2.x versions, so if it allows us to have 20% improvement, I would say: GO! The thinking about compatibility should occur before, not after and requires the establishment of more serious and stable rules (version_id, etc.)s
> -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of marc fleury > Sent: vendredi, 12. septembre 2003 01:28 > To: [EMAIL PROTECTED]; > [EMAIL PROTECTED] > Subject: RE: [JBoss-dev] Re: [jboss-group] revamping > Invocation objects > > > You guys are talking about a 3.3 proxy talking to a 3.2 server? > > If that is the case, it is not really relevant as most proxies are > dynamically generated. Or are you talking about portability of > interceptors working on the Invocation objects? > > The stability of 3.2 and its performance are priorities #1, 3.x will > live for MANY years > > marcf > > > -----Original Message----- > > From: [EMAIL PROTECTED] > > [mailto:[EMAIL PROTECTED] On > > Behalf Of Bill Burke > > Sent: Thursday, September 11, 2003 6:22 PM > > To: Private list for internal JBoss Group discussion; Jboss-Dev > > Subject: [JBoss-dev] Re: [jboss-group] revamping Invocation objects > > > > > > I'd rather not maintain something like that. What do you think? > > > > IMHO, we should guarantee over-the-wire compatibility only for a > > specific branch. over-the-wire compatibility should be breakable > > between major releases. > > > > Adrian Brock wrote: > > > > > On Thu, 2003-09-11 at 23:00, Bill Burke wrote: > > > > > >>Ok, I wouldn't be able to improve raw, over-the-wire, remote > > >>performance > > >>without breaking compatibility with older JBoss versions. > > >> > > > > > > > > > Would it be possible to set a property that provides backwards > > > compatibilty at serialization. Something similar to jmx 1.0 > > vs jmx 1.1 > > > serialized forms? > > > > > > Regards, > > > Adrian > > > > > > > > >>Bill > > >> > > >>Bill Burke wrote: > > >> > > >> > > >>>Only problem here is that what I've done so far is not backward > > >>>compatible with a previous version of JBoss. I guess this > > is important. > > >>> correct? I can make it compatible, but it will be a > > tiny bit ugly. > > >>> > > >>>I did increase performance for noop local interface calls > > for SLSB by > > >>>20%. > > >>> > > >>>Adrian Brock wrote: > > >>> > > >>> > > >>>>Ideally there should be no hashmap for normal usage. > > >>>>Using the principle: you don't pay for what you don't use. > > >>>> > > >>>>Regards, > > >>>>Adrian > > >>>> > > >>>>On Thu, 2003-09-11 at 20:02, Bill Burke wrote: > > >>>> > > >>>> > > >>>>>In our quest to improve performance, I'm doing a > redesign of our > > >>>>>Invocation object to minimize object creations and hash > > lookups. > > >>>>>I'll base it on some of Sacha's and my own observations. > > >>>>> > > >>>>>Just wanted to give some heads up just in case > somebody else was > > >>>>>looking at this too. > > >>>>> > > >>>>>Bill > > >>> > > >>> > > > > -- > > ================ > > Bill Burke > > Chief Architect > > JBoss Group LLC. > > ================ > > > > > > > > ------------------------------------------------------- > > This sf.net email is sponsored by:ThinkGeek > > Welcome to geek heaven. > > http://thinkgeek.com/sf > > _______________________________________________ > > JBoss-Development mailing list > [EMAIL PROTECTED] > > https://lists.sourceforge.net/lists/listinfo/jboss-development > > > > _______________________________________________ > jboss-group mailing list > [EMAIL PROTECTED] > http://mail.jboss.org/mailman/listinfo/jboss-group > > ------------------------------------------------------- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf _______________________________________________ JBoss-Development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
