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.
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.
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.
Regards,
Alan
