Ahh les tests unitaires. Dans le monde java si tu n'utilises pas c'est deux claques Pour les autres langages (Genre Delphi... grrr) c'est vrai que c'est moins simple même si les équivalents de JUnit se sont développés un peu partout.

Pour SVN (et avant lui CVS) l'imposer chez nous (SSII) a été un vrai squetch (comme les tests unitaires, les normes de codage et l'audit automatisé de qualité de code d'ailleurs). Aujourd'hui il semble que ce soit rentré un peu plus dans les moeurs. Pour GIT & Co. j'ai pas encore testé, j'avais lu avec interêt les argumentaires de Torvald sur le sujet sans pour autant me lancer dans l'aventure. SVN me va très bien pour l'instant et même les projets libres auquels je participe ne dépasse que rarement... 2 personnes ))

Pour le SVN de TuxIsAlive je te remercie de ton offre mais pour l'instant j'ai déjà un serveur fonctionnel. En revanche, si l'API intéresse des gens (c'est pas encore gagné cela serait pertinent de mirrorer les updates dessus pour plus de simplicité.

Pour répondre à ta question sur l'API je vais couper mon analyse en trois volets : protocole, logique et API python.

Aspect protocolaire

Les démons, tel que je les comprend, forment une sorte de "middleware". A ce titre, leur rôle n'est que de créer une abstraction "moyen-niveau" en convertissant de l'USB bas-niveau en accès TCP/IP-socket. De ce point de vue c'est très bien. Cela permet de l'attaquer par n'importe quel langage (tous ont un accès socket, moins un accès natif usb).

Le "hic" c'est qu'en restant au simple client/serveur TCP/IP, vu du côté API, c'est très très mais alors très "old faschion". Tant qu'à créer une abstraction, il aurait été sans doute plus pertinent d'adopter un formalisme type XML/WebServices sur une base protocole type HTTP. Cette approche permettrait :

1. de simplifier énormement le code des API en évitant toutes ces magouilles de cmd_struct & co. Tout en restant proche du système d'origine et doncd léger, les commandes et réponses seraient plus lisibles, facile à interpréter, sans cas particuliers.
2. de permettre une ouverture encore plus large à des techniques type "Ajax". En effet, le démon étant un serveur TCP/IP, s'il passe au stade au dessus et adopte un protocole HTTP/XML, se rend visible par des applications web dynamiques (Ajax). Sonny (un autre contributeur) pourrait ainsi faire une application FireFox qui contrôle le Tux. Pour l'instant, c'est impossible.

Logique interne du démon

Je ne sais pas ce que fait réellement le démon mais s'il se contente de convertir les "ordres" TCP/IP en "ordre" usb, pas de soucis.

En revanche, ce que je crains, s'il y a une logique interne en plus (comme gérer des compteurs, ou des états), là c'est un "problème" car il y a d'un point de vue fonctionnel cela fait un doublon avec l'API et un risque de complexité => des bugs potentiels. Les démons, pour moi doivent et doivent seulement jouer le rôle d'abstraction de l'usb bas niveau.

L'API python existante

Concernant l'API python elle-même, elle est du coup très proche de la philosophie du démon, d'où ton impression de "non structuration". Elle colle à la structure des trames et utilise les objets comme des "classeurs" de commandes.

La valeur ajoutée de l'API est du coup assez faible, c'est juste une nouvelle traduction du protocole bas niveau.

Si tu regardes le JavaDoc de l'API java, j'ai opté pour une philosophie transversale à celle-ci. L'objet n'est alors pas utilisé pour "classer" les fonctions du Tux mais pour, lui aussi, créer une abstraction, objet, du Tux faisant oublier (du moins j'espère la mécanique interne réelle. Cela donne des trucs du genre :

En conclusion pour moi, la raison d'être du démon est seulement de créer une abstraction USB/réseau et son évolution intéressante serait de gérer proprement et de manière moderne un protocole réseau type HTTP/XML normalisé (XmlRPC ou WebServices). S'il inclut de la logique interne supplémentaire, il fait doublon avec l'API.

J'espère que tout ce que je racontes n'est pas trop "confu" et que cela va aider.