mina-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Julien Vermillard <jvermill...@archean.fr>
Subject Re: [About the Filter Chain] Proposals
Date Wed, 05 Nov 2008 10:05:18 GMT
Hi Norval,

On Wed, 5 Nov 2008 11:39:00 +1100
"Norval Hope" <nrhope@gmail.com> wrote:

> Hi All,
> 
> I'm not a direct Mina user but rather someone who integrates with
> ApacheDS, and had to delve deep into the Mina 1.x code to fix a bug.
> Hence my opinions, for what they are worth, are those of an outsider
> who expects to be able to debug pretty much any code when I have a)
> the source and b) a running program. I can't agree that the MINA code
> I looked at as "great" - far from it. Rather - it took me two whole
> days to work out how to hack around a problem that was causing
> unintended buffering of search results (the intention was to have the
> results sent to the client as soon as they became available). I'd say
> the code I looked at was bordering on impenetrable, for a lot of the
> reasons Emmanuel has been describing (particularly the immensely deep
> call stack and associated difficulty when stepping in the debugger).

Glad to see someone speaking the truth ;)
and since 1.X  the core LoC doubled.

> 
> Hence I think the API is definitely in urgent need of simplification,
> and my usual expectation is that APIs are tidied up at major release
> boundaries. Personally I'd be much happier with a Mina 2.0 with a much
> simplified API - although I'm not using pre-release versions in
> production and therefore don't have some of the logistical concerns
> that others apparently do.

IMO 2.0 API is better than 1.0 one, the problem is mainly the internals.
Only the fitlerchain API is kludgy, and the IoFilter messageSent is
really problematic from a user POV. Just see the "Hey release soon
or now" calls from peoples who never lost 2 or 3 day digging in the
internal for simple issues. If you look at 2.0 for exterior, it's
looking OK and stable.

But the first serious bug report about core behaviour, I know exactly
what is going to happen... you spend a whole weekend stepping in your
debugger deciphering T legacy. I did it for
https://issues.apache.org/jira/browse/DIRMINA-609
cost me 2 days of vacations.

> 
> I don't know how much I represent the "possible users of MINA" and
> therefore whether my opinion is of any interest, but to summarize my
> thoughts:
>   1. I would definitely not use the Mina API directly without the
> proposed simplifications
>   2. I would definitely not wait a year for such an API if I had a
> need for one.
> 
> I'm not familiar enough with the Mina nuts and bolts to speak to how
> much has changed between Mina 1.1.7 and the current code, but would it
> makes sense to to release the current 2.0 code as a 1.2 (or 1.5) minor
> release, or:

Who is really familiar enough with MINA 2.0 nuts & bolts ? Even Emm who
is swimming in the core for few weeks is still having trouble with some
part of the code.

>   1. has the API already changed enough to break backward
> compatibility even without Emmanuel's proposed simplifications?
>   2. is an extra release too much additional work.
> 
> My 2c as well...
> 
> Thanks
> 
> On Tue, Nov 4, 2008 at 9:57 PM, Julien Vermillard
> <jvermillard@archean.fr> wrote:
> > On Mon, 03 Nov 2008 17:49:48 +0100
> > Emmanuel Lecharny <elecharny@gmail.com> wrote:
> >
> >> Niklas Gustavsson wrote:
> >> > On Mon, Nov 3, 2008 at 4:13 PM, Mark Webb <elihusmails@gmail.com>
> >> > wrote:
> >> >> I think we should focus on getting 2.0 out the door.  We have
> >> >> been working on it long enough and I think there are many
> >> >> people using it in production or near-production systems.  Once
> >> >> we release, we will probably get alot more feedback and can use
> >> >> that feedback to enhance/fix the next version.
> >> >>
> >> >
> >> > Big +1. We will find areas that we would like to improve during
> >> > the foreseeable future (this change and ByteBuffer comes to
> >> > mind).
> >> >
> >> yop. And I don't see how we can include that in 2 weeks...
> >> > Including all such changes will delay 2.0 for a long time, long
> >> > enough for MINA to get behind other frameworks. Having a real
> >> > release out will mean getting further feedback from users, so
> >> > far I haven't seen a lot of users requesting this change nor the
> >> > ByteBuffer change. I think we're too critical, the code is great.
> >> Well, IMHO, the code works. Saying that it's great is another
> >> story :) (but this might just be a matter of taste ...)
> >>
> >> Anyway, I agree with what you say. We don't release fast enough.
> >> Atm, regardless to the current code quality, and performance, I
> >> think MINA 2 is usable, even if there are still some issues to
> >> fix. I will do some quick perf tests on ADS with MINA 2 and give
> >> you some feedback soon.
> >>
> >> > Release early, release often.
> >> > We do neither.
> >> >
> >> eh ;)
> >> >
> >> >> I would think that we should move right
> >> >> towards 3.0.
> >> >>
> >> >
> >> > I say go work on a branch (as already suggested) and see where
> >> > that leads.
> >> There is a new branche for such experiment. Branching is certainly
> >> the way to go, whatever we do regarding the release !
> >>
> >> I would like to let this thread go for a little bit (let's say a
> >> couple of days), and then, I think we will have to vote : going for
> >> 2.0-RC or modify the code massively.
> >>
> >
> > I think it's a good idea.
> > Let's wait few days for see where the branch is going. If it's
> > looking like a viable and an interesting simplification then let's
> > vote for choosing between integration or post-pone.
> >
> > Julien
> >

Mime
View raw message