> It is true, but this helps you keep track of open connections, right? > You can easily add more control logic around ConnectingIOReactor in > addition to that. > > So, i think a viable approach could be to build the connection > management code as an extra control layer on top of both IOEventDispatch > and ConnectingIOReactor interfaces. A connection manager would act as a > facade for the connecting I/O reactor. It could keep track of open > connections and delegate the process of establishing new connections to > the I/O reactor if needed. The user would interact with the connection > manager and not directly with the I/O reactor. > > Does this make any sense?
Yes, this makes very much sense. We swap in our NIO layer (which essentially is our own version of an IOReactor, used across the entire program for many other things) by having a ConnectingIOReactor implementation that delegates to our stuff. If the connection manager layer delegates to the ConnectiongIOReactor & IOEventDispatch, it will continue to easily work with other NIO layers. I do think that any nio-based connection manager will need to have much finer-grained control than the blocking variant. That is, some additional ability to say, "Do I have a latent connection to host X? If so, give it to me. Otherwise, don't even bother connecting because I want to do something else." This is strictly from our use-case though of wanting to optimize what sources are used. Sam
