Consider adaptation via IOLoop interface for 1.0.0

I created this issue to bounce an idea off the maintainer community.

Presently in pika’s async world (e.g. SelectConnection, Tornado connection, AsyncioConnection) various APIs that normally belong in ioloops appear to be misplaced in connection adapter classes. Those are the likes of add timeout, remove timeout, etc. Those APIs traditionally belong in the ioloop, and I think it would be cleaner to remove them from the connection adapters and only expose them from the ioloop adapters of the specific ioloop adaptations.

Furthermore, on a related note, these async connection adapters are presently implemented via a (somewhat arbitrary) combination of subclassing BaseConnection and overriding some of its (and possibly Connection’s) members and a native ioloop wrapper. I think it would be cleaner to define an abstract ioloop interface as the primary means of adaptation which makes it very clear what needs to be implemented. This way, there would be no need for TornadoConnection, etc. An app could simply instantiate a generic pika-provided async connection class (e.g., pika.AsyncConnection) passing its constructor the specific ioloop adapter instance (e.g., pika.TornadoIOLoopAdapter()). Having a well-defined abstract IOLoop adapter interface as the primary means for adaptation should improve stability of the adaptations by eliminating the guess-work of what needs to be overridden and reducing code paths that need to be tested, thus better leveraging common/shared test code. That said, adaptations could still provide specific Connection classes as needed, for example to extend the API with some native ioloop features such as futures.

I realize that pika already has the major ioloop adaptations covered, so this proposal is largely for cleaning up the API and existing integrations.

Your thoughts?

[vitaly-krugl]

I am hoping to get the apps away from accessing the connection’s internal ioloop, which is often an adapter on top of the native I/O loop. I would not want them to depend on any connection.ioloop API (that’s should really be just for the benefit of adapter implementations), calling it’s start/stop method, etc. (it shouldn’t be even providing a start() and stop() methods). Instead, apps should be interacting directly with the native I/O loop - calling the native loop’s start(), run_forever(), stop(), add_timeout(), etc.

[gmr]

Just dropping a note to let you know I’ve seen this and am digesting it.