Ton approche est juste, le démons doit être une abstraction protocole (USB) et hardware. Mais comme toujours la frontière est mince. Par exemple (je ne sais pas si c'est le cas même si je me doute). Les fonctions Open et Close sont pour moi de l'ordre du haut niveau (API) et n'ont rien à faire dans le démon. En revanche, la bufferisation des status, elle, me parrait plus du domaine du démon avec un process du type:

 - État présente dans le buffer ? 
    - Non, faire la requête au hardware, attendre la réponse (cf process suivant)
 - Revoyer la valeur à l'API

et d'un autre côté dans la boucle de démon

  - Réception d'un status du hardware 
    - mettre en buffer
    - envoyer la commande de retour status à l'API

Ca, ca simplifierait gravement l'API pour un job qui n'est pas vraiment le sien. En gros, pour compléter ce que je disais avec ce que tu viens d'ajouter, de démon est :

1. une abstraction protocole qui a tout a gagner à passer en HTTP/XML
2. Une abstraction hardware qui cache/simplifie sa mécanique mais qui n'ajoute pas de nouvelle fonctions.

Ainsi tu aurais une approche "propre":

Pour ce qui est de la simplification des bindings, oui, il y a une méthode. Elle consiste à écrire une API non pas en python mais en C/C++. Ainsi tu peux générer un bind quasi automatique des headers vers les langages cibles. L'erreur serait à mon sens de fusionner cette idée avec celle du démon qui ne doit pas sortir du périmètre dont nous parlons. Mais sorti de là, une lib/API en C va pouvoir servir de graine à toute une génération de bindings sans grands efforts.

Après cela n'empêche pas de faire des API "full XXX" comme la mienne en Java, tu ouvres les possibles, tu ne les fermes pas. Dans la même idée, plus rien n'empêche des lors de que l'on dispose d'un démon et d'une Lib/API de faire de l'hybridage. Par exemple ton claquement de mains trouvera sa place très logiquement dans la lib que mon API peut utiliser, ou pas. Si en java je dispose de fonctions de reconnaissance audio plus avancées, je ne suis dés lors pas bloqué pour les utiliser. Si tu le place au niveau du démon, c'est moins sur.

En effet, c'est très intéressant, mais ce Tux EST intéressant car il est un labo en miniature d'une myriade de techniques et concepts complexes. Le portage en Java n'a certes pas été simple mais très instructif, ça s'est sur.