mina-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Edouard De Oliveira <doe_wan...@yahoo.fr>
Subject Re : [About the Filter Chain] Proposals
Date Mon, 03 Nov 2008 22:49:23 GMT
Hi all,

Been away for some time being very busy...

IMHO, "Release early, release often" should absolutely be our rule
As previously said MINA 2.0 as been longly awaited so i'd vote to release it as soon as possible
by
removing all big changes maybe also being light on documenting parts we know would change
(perhaps these docs can be fixed along the way trying to understand what has been done internally)
.

We should fix the basic issues and keep the new ideas for an implementation in MINA 3.0.

One other thing i though we should improve is redesign internals to
better handle handshake processes i.e without having to hack to buffer writes during handshakes
or prevent events like SESSION_OPENED from going down the chain while handshake has not 
finished by providing some kind of control on these.

Hope these lines put some light on the way
 Cordialement, Regards,
-Edouard De Oliveira-
http://tedorg.free.fr/en/main.php




________________________________
De : Mark Webb <elihusmails@gmail.com>
À : dev@mina.apache.org
Envoyé le : Lundi, 3 Novembre 2008, 18h01mn 00s
Objet : Re: [About the Filter Chain] Proposals

I agree completely with all of Niklas's comments.



On Mon, Nov 3, 2008 at 11:49 AM, 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.
>
> --
> --
> cordialement, regards,
> Emmanuel Lécharny
> www.iktek.com
> directory.apache.org
>
>
>



      
Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message