james-server-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefano Bagnara <apa...@bago.org>
Subject Re: MINA integration
Date Wed, 12 Jul 2006 18:29:16 GMT
Noel J. Bergman wrote:
>> Imho James 3.0 won't be out before mid 2007 (optimistic)
> That's not anyone else's goal, so I hope that it isn't yours.  I'd like to
> see JAMES v3 by year end.  But it all depends upon what one calls JAMES v3.

It's not a matter of goals, but what I guess.

Only a fool can think we will have a 3.0 final out by the end of the 
year if you want at least to add IMAP and something more to it.

Btw, I don't really want to discuss about this. Maybe I will be wrong 
and that you will be payed to work fulltime from now to december on 
James 3.0, or any other miracle :-)

If you agree that we can start including MINA alternatives for our 
protocols we'll decide in mid 2007 what to do with "non MINA services".
Maybe you are right and that we'll release James 4.0 in mid-2007 with 
only MINA.

Imho it would be a good step if people would help on releasing 2.3.0 
final by september. This would be a great goal.

>> Otherwise we could start implementing MINA based services while keeping
>> old services updated.
> We should maintain both.  MINA is essential for scaling to large numbers of
> connections, and for STARTTLS, but not for the majority of JAMES users.

Mantaining both will probably be an additional cost that will not bring 
anything in the long time. Btw we'll vote about this in mid-2007 ;-) We 
can skip this war now...

>> Imho most of the code should be shared between MINA and non MINA services.
> +1
> That was always the intent.  The protocol handler should not care how it
> gets the next package of data, just that it does.  And, happily,
> telnet-class protocols are line-oriented, making things easy.
> 	--- Noel

This is valid for MINA low-level APIs but not for MINA high-level APIs.
MINA high-level APIs introduce the concept of message objects and codecs 
and we don't have this concept in James now.
Imho it would be good to analyze even the high-level APIs and maybe 
we'll not be able to share as much code with what we have now (our 
handlers currently directly write strings to the socket outputstream).


To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org

View raw message