On Feb 4, 2010, at 4:43 AM, Ashish wrote:
On Thu, Feb 4, 2010 at 3:18 PM, Emmanuel Lecharny
<[email protected]> 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,
WDYT?
Regards,
Alan
