akarasulu 2004/03/15 19:38:22 Added: www/community/who noel.html www/subprojects/eve/frontend misc.html Log: small changes noels profile and to the frontends misc page Revision Changes Path 1.1 incubator-directory/www/community/who/noel.html Index: noel.html ===================================================================
All aspects of the server will be based on non-blocking IO constructs. There simply is no point to writing a stateful protocol server any other way. The code of the server could be designed to support any implementation whether it based on blocking IO or not.
The frontend from the ground up is designed to use non-blocking IO and it makes even less sense to consider anything else when the SEDA based approach is also considered.
A primary requirement on the server is to remain pure Java compliant. That means we're left with whatever the JDK gives us in terms of non-blocking mechanisms. We are pretty sure that Selectors and Channels are the construct from now until a very long time. Now this may change and adaptation may be required but its a ways out if at all.
There is no point to us writing generic code to accomodate blocking IO. It should not really matter to us if some of the details of the standard non-blocking constructs of the JDK leak out reveiling a non-blocking implementation. Who cares? Why was the time bothering with the old way of doing things?
We try not expose our non-blocking implementation details but they have leaked out in minor areas. Monitors for the input and listener modules show methods taking Selectors and their keys. This is ok with us for now because well the monitor needs deal with failures in the selection process. They are not core functional components and can be changed over time. Nothing critical like a component's service interface exposes these NIO classes.