I wrote a bunch of stuff inline in response to Jusin's API layout post, and then realized it probably deserves its own email.
For some background, we had previously discussed the notion that we might want to add mulitple completely independent reactor implementations. My thinking on this point has evolved a bit after some implementation experience. With the C impl I've been able to completely decouple the I/O from the reactor. All the I/O is done as a global handler that you can replace or remove entirely. When you replace it you can provide your own I/O implementation in whatever language you want, and when you remove it entirely the Reactor simply functions as a dispatcher that processes events for you. This gives us a single reactor that you can use as a main loop but still trivially supply a completely custom I/O handler. You can also use it from inside an external main loop purely as a dispatcher. This basically leaves only the dispatch logic and a few core APIs around selectables as the only uncustomizable part of the reactor, and that means we don't really need multple reactors inside proton, since the handlers themselves can customize every relevant aspect of behavior. (Customizing dispatch logic and/or not having a common core API around registering selectables would break compatibility between handlers and so isn't terribly useful to customize.) There's also a significant benefit to having just one reactor (or at least one base class for all reactors that wraps a C reactor) since the events themselves can all point back to the reactor. This allows C handlers to do very useful things like open file descriptors and use the reactor to create selectables for them. These selectables can then get serviced by whatever I/O handler the reactor has. This allows a level of seamless interoperation between handlers written in different languages that is extremely useful. --Rafael
