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).
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. 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: 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 <[EMAIL PROTECTED]> wrote: > On Mon, 03 Nov 2008 17:49:48 +0100 > Emmanuel Lecharny <[EMAIL PROTECTED]> wrote: > >> Niklas Gustavsson wrote: >> > On Mon, Nov 3, 2008 at 4:13 PM, Mark Webb <[EMAIL PROTECTED]> >> > 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 >
