Super intéressant. En fait moi, en abordant le daemon par le firmware et l'USB, je le vois également comme une abstraction de l'USB mas également du fonctionnement du hardware. Exemple, la mesure de lumière est un peu complexe, la mesure comprend la valeur de 10 bits et 1 bit qui indique si on est en mode basse ou haute lumière. En gros, si la lumière passe de rien (noir) à très forte (soleil), la mesure va de 0 à un peu plus de 1000 en mode basse lumière puis on atteint le seuil où on pass en mode haute lumière et la valeur retombe à disons 200 et remonte jusque 1024. Dans le daemon, on recompose ça pour n'avoir qu'une valeur de lumière qui évolue très approximativement de façon linéaire et varie de 0 à 1128, c'est l'abstraction du fonctionnement interne des capteurs. Pareil, si pour passer en mode sleep, il faut envoyer une série de commandes successives, l'API doit être simple et le daemon décompose la fonction sleep en ce qui est nécessaire.
Par exemple pour récupérer les versions des différents processeurs, est-ce que ce ne serait pas le daemon qui devrait questionner les procs tour à tour et garder les versions dans une structure qui serait simplement retournée au client (api python ou java) quand il le demande?
Pour les statuts de tux, je trouve qu'il y a des trucs qui ont plus de sens que la valeur de tous les bits des I/O des processeurs. Le statut CHARGEUR pourrait simplement être dans plusieurs états, et le daemon s'occuperait de déterminer l'état en fonction de tous les bits (pluggé, en charge, fin de charge, pas de tension si le transfo n'est pas branché dans la prise, ...). L'intérêt, c'est vraiment de faire abstraction du hardware au niveau daemon. Cela faciliterait le développement de clients dans plusieurs languages puisque les specs dprotocole du daemon se simplifieraient.
En fait, tu es le premier à te lancer à traduire l'api python vers autre chose, mais moi ça me semble assez infaisable. En tout cas je me dis qu'il doit y avoir plus simple dans la structure et répartition des tâches entre le daemon et l'api pour qu'on puisse facilement la porter vers d'autres languages. Et pour moi déplacer tout ce qui est gestion du hardware dans le daemon est une simplification. Maintenant est-ce qu'il n'y a pas des méthodes pour générer des bindings d'un language vers un autre? Ou c'est mieux d'écrire l'api dans tous les languages?
Pour aller encore plus loin, je me demandais si des trucs comme détection d'un claquement de main ou d'un niveau de bruit ne pourrait pas également être fait par le daemon pour enrichir les statuts et ne pas devoir faire ce traitement dans tous les languages.
Enfin bon, c'est probablement pas très clair mais c'est un premier jet , la discussion est intéressante en tout cas
Super intéressant. En fait moi, en abordant le daemon par le firmware et l'USB, je le vois également comme une abstraction de l'USB mas également du fonctionnement du hardware. Exemple, la mesure de lumière est un peu complexe, la mesure comprend la valeur de 10 bits et 1 bit qui indique si on est en mode basse ou haute lumière. En gros, si la lumière passe de rien (noir) à très forte (soleil), la mesure va de 0 à un peu plus de 1000 en mode basse lumière puis on atteint le seuil où on pass en mode haute lumière et la valeur retombe à disons 200 et remonte jusque 1024. Dans le daemon, on recompose ça pour n'avoir qu'une valeur de lumière qui évolue très approximativement de façon linéaire et varie de 0 à 1128, c'est l'abstraction du fonctionnement interne des capteurs. Pareil, si pour passer en mode sleep, il faut envoyer une série de commandes successives, l'API doit être simple et le daemon décompose la fonction sleep en ce qui est nécessaire.
Par exemple pour récupérer les versions des différents processeurs, est-ce que ce ne serait pas le daemon qui devrait questionner les procs tour à tour et garder les versions dans une structure qui serait simplement retournée au client (api python ou java) quand il le demande?
Pour les statuts de tux, je trouve qu'il y a des trucs qui ont plus de sens que la valeur de tous les bits des I/O des processeurs. Le statut CHARGEUR pourrait simplement être dans plusieurs états, et le daemon s'occuperait de déterminer l'état en fonction de tous les bits (pluggé, en charge, fin de charge, pas de tension si le transfo n'est pas branché dans la prise, ...). L'intérêt, c'est vraiment de faire abstraction du hardware au niveau daemon. Cela faciliterait le développement de clients dans plusieurs languages puisque les specs dprotocole du daemon se simplifieraient.
En fait, tu es le premier à te lancer à traduire l'api python vers autre chose, mais moi ça me semble assez infaisable. En tout cas je me dis qu'il doit y avoir plus simple dans la structure et répartition des tâches entre le daemon et l'api pour qu'on puisse facilement la porter vers d'autres languages. Et pour moi déplacer tout ce qui est gestion du hardware dans le daemon est une simplification. Maintenant est-ce qu'il n'y a pas des méthodes pour générer des bindings d'un language vers un autre? Ou c'est mieux d'écrire l'api dans tous les languages?
Pour aller encore plus loin, je me demandais si des trucs comme détection d'un claquement de main ou d'un niveau de bruit ne pourrait pas également être fait par le daemon pour enrichir les statuts et ne pas devoir faire ce traitement dans tous les languages.
Enfin bon, c'est probablement pas très clair mais c'est un premier jet
, la discussion est intéressante en tout cas