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 21:53:55 GMT

On Feb 4, 2010, at 4:43 AM, Ashish wrote:

> On Thu, Feb 4, 2010 at 3:18 PM, Emmanuel Lecharny  
> <elecharny@gmail.com> 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.
> Sorry, but I don't get this part completely. Do you mean that
> IoService ought to have an API which provides direct access to write
> queue?
> My knowledge in this part is limited :-(
>> 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 think broadcast() should be part of IoAcceptor, to broadcast a
> message to all active session. Don't think it makes sense to have it
> for Connector.

Looking at the current implementation of broadcast and am wondering  
why it's in the library.  It seems very application specific.  What is  
the use case for this?  I'm sure there is one, it just doesn't come to  
mind for me atm.

> Also, what abt the "IoSessionDataStructureFactory", do we need an API
> for plugging in this stuff?

I think that configuration and session attributes should be merged  
into a single first class mechanism.  It will make the API simpler,   


View raw message