mina-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Emmanuel Lecharny <elecha...@gmail.com>
Subject Re: [MINA 3.0] IoService definition
Date Wed, 10 Feb 2010 22:08:19 GMT
On 2/10/10 10:42 PM, Alan D. Cabrera wrote:
> On Feb 4, 2010, at 1:48 AM, Emmanuel Lecharny wrote:
>> Hi,
>> some more thoughts, as I'd like to define precisely what is an 
>> IoService.
>> Looking at the existing code, I would define an IoService as a base 
>> Interface for Acceptor and Connector, describing the relationship 
>> between all their components, namely :
>> - the chain
>> - the handler
>> - the configuration
>> - a state (active/not active, number of sessions, is the service is 
>> disposed, or being disposed...)
>> - the write log (messages waiting to be written to the client)
>> I'm not convinced that the write log accessors should be a separate 
>> component. In fact, I would rather see that as a part of the 
>> service's state.
>> Is that correct? Fo I miss something here ?
>> Also there is some strange method present in this interface, like 
>> broadcast(). I'm not sure it should be a part of the IoService 
>> interface, but rather moved to IoAcceptor (does it make sense for a 
>> Connector to boradcast a message ?)
> I'm not a big fan of tightly coupling the Acceptor and Connector via a 
> base interface IoService unless there's a concrete and compelling use 
> case where I would want to interchangeably use either.
The thing is that they are using the exact same mechanisms, the only big 
difference is that one initiate the connection, the other one accept 
them.  But we may see more difference if we look in detail.
> I also think that the modus operandi for the API redesign is to start 
> w/ apps first, generate interfaces that support those apps, then fill 
> in the guts.  Starting with the existing API tends to limit the 
> possible ideas and one tends to accidentally bring in some of the less 
> worthwhile bits.
Here, I would slightly disagree, if we want to stay close t what we 
currently have to ease migration.
> I invite people to look at my HTTP code in my sandbox where I am 
> sketching out some ideas of a possible mina 3 API.  It's a sketch and 
> there's a ton of bits that have not even been thought off.  I welcome 
> your comments.
Sure, will do.

Emmanuel L├ęcharny

View raw message