mina-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Alan D. Cabrera" <l...@toolazydogs.com>
Subject Re: [MINA 3.0] IoService definition
Date Wed, 10 Feb 2010 22:24:36 GMT

On Feb 10, 2010, at 2:08 PM, Emmanuel Lecharny wrote:

> 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 think that I can correctly restate your words as:

The methods in the parent interface, IoService, that would be shared  
by the Acceptor and Connector have the same semantics.  This is why it  
makes sense to me to push the methods into IoService and have them  

If my re-wording is correct then I am going to still hold on to my  
point.  An interface should not be used as an indicator for  
implementation.  Which, imo, is the justification you give.  To my  
mind an Acceptor and Connector live in two different worlds and one  
would never pass around both willy nilly using the base interface.   
Maybe there's a use case for doing so.  I cannot think of one off the  
top of my head.

>> 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.

Imho, the vein of ideas that influenced v1.x and v2.x has run its  
course.  v2.x was an attempt to "remedy" the issues of v1.x but, imho,  
things got way more complicated and bloated.  This is why I was  
thinking of a radical departure.

If you want to keep backwards compatibility then why not do it in the  
2.x branch?

>> 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.

Many thanks.  Please be genteel with your comments.  ;)


View raw message