mina-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Emmanuel Lecharny <elecha...@gmail.com>
Subject Re: [About the Filter Chain] Proposals
Date Wed, 05 Nov 2008 11:46:27 GMT
Julien Vermillard wrote:
> Hi Norval,
Hi Julien, Norval,

more comments inline...
> On Wed, 5 Nov 2008 11:39:00 +1100
> "Norval Hope" <nrhope@gmail.com> wrote:
> <snip the comment on the impenetrable code ;) />
>> 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,
Most certainly, yes. Switching to MINA 2 from MINA 1 was a piece of 
cake, if you consider the deep changes made in the API. It took me 2 
days to had ADS working with MINA 2 (but I must admit I spent almost 2 
weeks working on a small sample to be sure I won't FU ADS completely 
doing so - of course, it was not full time ! -)

The current API, from an external POV (ie : if you don't have to delve 
into the code to debug it, as I had to do), is pretty OK. You can really 
build a quick and working client/server system based on MINA 2.
>  the problem is mainly the internals.
Damn yes !
> Only the fitlerchain API is kludgy, and the IoFilter messageSent is
> really problematic from a user POV.
Well, I also have deep concern about the IoBuffer, which is, IMHO, a 
massive design error (excuse me for expressing my vocal opinion). And 
there are other areas which are really problematic : throttling 
management, all those Future everywhere, the IdleThread, inconsistent 
Filters implementations, and a few more, including the almost 
undocumented choices done.
>  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. 
Ok, let's phrase it differenlty, because many has expressed a very valid 
opinion about this 'release often, release fast' moto, and they _have_ 
spent days digging into the code. At some point, I must say that I'm 
really balancing between the need for a better 2.0 and the fact that all 
those changes could also be done more easily in a 3.0.

This is certainly not a technical discussion, but much more a 
'political' one : if we release a 2.0 soon (and I see no reason to 
postpone beyond end of this year a 2.0 final, which means we should then 
go for a RC1 by the end of nov), then we will have users, and bug 
reports, and fixes, and minor versions. Plus we will have more users 
telling us 'hey, why the hell are you chaning the API in 3.0 ???'. OTOH, 
if we postpone 2.0 to include the current modifications, then I think 
it's a 6 months delay, at least, something we may not want to accept.

I guess that it worth a vote at this point ...
> If you look at 2.0 for exterior, it's
> looking OK and stable.
Almost true. Let's say it's usable. Not very performant, but usable. 
(btw, I would like to know if we have some gain against MINA 1.0 at this 
point, and if so, how much ?)
> 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.
Working on an ASF project is a pleasure :) You didn't lost two days of 
vacations, you just enjoyed two days fishing for nasty bugs ;)

Seriously, I understand and share your concern on that. I spent one full 
day trying to understand why we were loosing messages with MINA 2.0 
until I found a nasty bug in the new version of ProtocolCodecFilter... 
But, hey, sh*t happens ! Bugs are bugs.
>> 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.
This is also a pb : we should have been more involved in the code. I'm 
suffering because I didn't spent enough time in the past to get involved 
and avoid such a situation. As a PMC, I feel responsible for that.
>>   1. has the API already changed enough to break backward
>> compatibility even without Emmanuel's proposed simplifications?
Switching from 1.0 to 2.0 is not a free ride, that's for sure. But it's 
not a real pain too. We have refactored the core package, splitting the 
hundred classes into more specific packages, and the ByteBuffer class 
has been renamed IoBuffer. But as you are using MINA 1 inside an 
ADS-patched server, and as I'm almost done with the MINA 1 -> 2 
migration, this should not be a burden for you.

PS : I did this migration because this was on our roadmap, and also 
because we wanted to fix the OOM problem you found. I think that I have 
a solid solution for this problem, but we will discuss that on the ADS ML.
>>   2. is an extra release too much additional work.
Releasing is easy. usually, a day of work. But then, if we have to start 
a 3.0 just after this release, we will have to refactor the site, write 
some migration guides, etc. Costly ...

cordialement, regards,
Emmanuel L├ęcharny

View raw message