On Wed, 05 Nov 2008 12:46:27 +0100 Emmanuel Lecharny <[EMAIL PROTECTED]> wrote:
> Julien Vermillard wrote: > > Hi Norval, > > > Hi Julien, Norval, > > more comments inline... > > On Wed, 5 Nov 2008 11:39:00 +1100 > > "Norval Hope" <[EMAIL PROTECTED]> 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 ?) The last test I did 2.0 was much faster (read x2) than 1.1.7, I wait for ADS first results :) > > 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. Yes bug hunting is part of the job, but deciphering code isn't really. I won't explain that to you who dive everyday in the pile of dirt :) > > > >> 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. We are all responsible, and me a bit more cause I should have pushed more when the issues with T was raised, but it's past now. We are going to pay our debts today :) > > > >> 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 ... Yes a release is 1/2 day for M or RC, for a .0 we need more announcement, so it's 1 day or 2. Julien
signature.asc
Description: PGP signature
