Neues Feature für Plug-In: Server basierend auf lib.network oder lib.connection?

[jentz1986]

Hallo Gemeinde,
Ich lese im Code und in der Doku immer mal wieder davon, dass lib.connection "softly" von uns gehen wird. Wenn ich jetzt eine neue Funktionalität bauen will (Server, der ArtNet-Anfragen entgegennehmen kann), basiere ich diese auf auf der klassischen lib.connection oder fange ich an, dies auf der "neuen" lib.network zu bauen, die "This is early work in progress. Interfaces are subject to change" noch in der Mache ist?
Gleiche Stoßrichtung bei der Frage, wenn ich als Client eine Socket-Connection nach außen aufmache.

[bmx]

Sowas ist eigentlich eher eine Frage für den Gitter Chat. Prinzipiell ist die lib.connection in der jetzigen Form mit kqueue oder event nicht portabel.
Daher hat Foxi352 die lib.network entwickelt. Diese setzt auf asyncio auf. Nun hat sich in diesem Feld gerade seit der Python 3.4 noch einiges getan und von daher ist das nicht als stabil zu sehen gewesen. Mit dem Release 1.6 wird das da sicher weitergehen können.
Insofern würde ich jetzt in der Zwischenzeit zum nächsten Release sicher auf lib.network setzen wollen wenn ich ein Plugin neu entwickeln müßte...

Das Ziel sollte bei Entwicklungen im Core und idealerweise auch bei den Plugins immer seit möglichst portabel zu sein, also als Platform nicht nur Linux zu erlauben, sondern auch OS X und zukünftig Windows.