![](https://secure.gravatar.com/avatar/ebf132362b622423ed5baca2988911b8.jpg?s=120&d=mm&r=g)
On Nov 26, 2014, at 9:30 PM, Nick Coghlan <ncoghlan@gmail.com> wrote:
On 27 November 2014 at 03:35, Paul Colomiets <paul@colomiets.name> wrote:
Hi,
I've written an article about how I perceive the future of asynchronous I/O in Python. It's not something that should directly be incorporated into python now, but I believe it's useful for python-ideas list.
https://medium.com/@paulcolomiets/the-future-of-asynchronous-io-in-python-ce...
Thanks Paul, that's an interesting write-up.
Another couple of potentially relevant projects in the higher level "service discovery" space (beyond Zookeeper, which you already mention) are Fedora's fedmsg (http://www.fedmsg.com/en/latest/ - since also adopted by Debian I believe) and the Zato ESB project (https://zato.io/). Those are the kinds of things a service discovery plugin system would want to be able to handle.
We’re using consul for service discovery in psf-salt FWIW. It’s been pretty good for us so far. It implements service discovery along with health checks so that if a service starts failing health checks it gets kicked out of the service discovery rotation for that service. It also implements a DNS resolver so you can use DNS to discover instead of it’s API if you want. --- Donald Stufft PGP: 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA