> Pour essayer de conclure et d'archiver le truc.
> 2 methodes, read et write pour tout le monde. Si autre, on leve une erreur.
> A mon avis on peut egalement en profiter pour definir les signaux.
> je dirais un signal, nommé intérupt qui fournit un code correspondant a un
> evenement, par exemple 1=> la valeur a changé (que ce soit pour un actuator
> ou un sensor)
> A la limite on peut prevoir un variant en plus, qui permet de filer d'autres
> info.
>
> Apres on normalise le nom des ifaces (au moins le prefixe) histoire que les
> client retrouvent leur petit
> on pourait avoir un truc du style :
>
> iface générales : org.openplacos.*
> ex : org.openplacos.analog, org.openplacos.digital, org.openplacos.rcswitch
> etc
>
> ifaces de commandes : org.openplacos.order.* , qui permettent de spécifier
> au client qu'on est plutot en presence d'un effecteur, avec un certain
> nombre d'entre elle normalisé par type de commande :
> ex: org.openplacos.order.switch, org.openplacos.order.dimmer etc
>
> ifaces de sensors : org.openplacos.sensor.<grandeur_physique>.<unité>
> ex: org.openplacos.sensor.temperature.celsuis
>
> apres je pense qu'on est d'accord que cette normalisation n'implique rien du
> coté server, c'est plus pour que les clients puissent faire du pattern
> matching et presentent les bon truc.
> par contre, ya encore quelques points ou ca coince. par exemple une régule
> ne saura pas sur quoi se branché car elle est indépendante de la gradeur
> physique et de l'unité.
> apres on a aussi des iface avec des nom différent qui sont compatible, par
> exemple une digital peut se brancher sur une pwm etc
>
> pour en discuter...
>
> Le 18 juillet 2011 19:10, miaouf kirsh <
miaoufkirsh@xxxxxxxxx> a écrit :
>>
>> yop,
>> je suis globalement d'accord, mais j'ai pas saisi la solution proposé.
>> je suis completement dac qu'on peut tout faire avec du read et du write,
>> au final c'est bien ce qu'on fait avec les drivers (tout passe par un
>> drivers).
>> apres j'aimais bien l'idée de méthodes de haut niveau style on/off qui ne
>> sont que des raccourci pour des write.
>> Je vois mal laisser uniquement du read et du write coté client. disons que
>> on niveau client ca oblige a faire des truc du style "ok , iface digitale +
>> write = bouton On/Off" mais dans le cas que tu cite (bouton avec 30s), ben
>> le client peut rien faire vu qu'il ne connais pas l'iface, ou du moins il va
>> entrer un champ texte pour que l'user set ca valeur.
>> On vois bien que avec les regul c'est pas exellent d'un pts de vu
>> expérience utilisateur.
>> Le 18 juillet 2011 18:25, flagos <
flagospub@xxxxxxxxx> a écrit :
>>>
>>> Yep,
>>>
>>> La dessus, je pense qu'on doit tout de meme pouvoir se ramener a un
>>> ensemble de quelques fonctions qui mettent tout le monde d'accord. Mis
>>> a part le probleme du passage de parametre, au final on va tout de
>>> meme tomber toujours sur les memes actions. Un peu comme REST et ses 4
>>> methodes avec lesquelles on peut tout faire.
>>>
>>> J'ai tendance a penser que si le gonze veut faire de la daube sur un
>>> composant et présenter des methodes alambiques, c'est qu'en réalité il
>>> devrait utiliser une autre interface de la meme pinoche pour le faire.
>>>
>>> Exemple concret: je code un controleur 2 etats, le bete bouton on/off
>>> en somme. Pis je me dis: tiens ce serait cool de caler un bouton
>>> poussoir: Comme dans une cage d'escalier, je veux un truc qui reste
>>> allumé genre 30 secondes et qui rebascule sur off. Bon ca pourrait se
>>> faire dans un composant surcouche mais passons. Quelque part, il faut
>>> eviter que le gonze se mette a enrichir ses methodes. Je pense qu'il
>>> faut plutot qu'il ajoute une iface
>>> "bouton_poussoir_comme_dans_les_cages_d'escalier" dans laquelle on
>>> aurait une unique fonction read avec un entier en argument.
>>>
>>> Enfin voila, je pense qu'il faut etre souple sur les interfaces
>>> proposées mais par contre tenir la bride du coté des méthodes: 4 comme
>>> dans CRUD (voire 2 puisque nous on fait tout avec 2 methodes), ca
>>> devrait suffire.
>>>
>>> Apres, comme tu le soulignes et c'est je pense tres important: ces
>>> fameuses interfaces (ou methodes) un poil exotiques, elles n'ont
>>> d’intérêt que si elles exploitées derrière. En pratique, le plus
>>> facile est qu'elles soient contrôlées directement par l'utilsateur.
>>> Apres, contraindre a n'avoir que les objets terminaux d'un peu
>>> exotiques, c'est un peu contraignant, genre si le gonze a développé
>>> une regule sur une iface tordue en plus d'avoir codé le composant,
>>> c'est cool quand meme: je pense pas qu'on ait besoin d'aller jusque la
>>> non ?
>>>
>>>
>>> Le 18 juillet 2011 11:07, miaouf kirsh <
miaoufkirsh@xxxxxxxxx> a écrit :
>>> > Salut
>>> > Une question qu'on a soulevé a la derniere séance codage et qu'on a
>>> > legerement évitée.
>>> > On avait fait un joli travail de normalisation pour les drivers et je
>>> > me
>>> > demande si ca peut rester d'actualité avec la nouvelle architecture.
>>> > personnellement, je trouve pas mal d'avoir des methodes un peu haut
>>> > niveau
>>> > (style On/Off ) au niveau du bus client, que ce soit pour les
>>> > actuator/sensors, ou pour les reguls etc
>>> > vu qu'on a mis un peut tout a plat sur le meme niveau, j'ai du mal a
>>> > envisager comment on pourrais forcer la normalisation niveau driver et
>>> > autoriser une pareille souplesse pour les autres.
>>> >
>>> > Le principal probleme,il me semble, est de pouvoir garder un peut de
>>> > souplesse tout en evitant que ce soit la foire.
>>> > Le read est le write coté drivers permetait d'assurer en quelque sorte
>>> > une
>>> > compatibilité entre les différents composants pour méthodes ayant des
>>> > fonctionnalité similaires.
>>> > Le truc que je me dis c'est qu'on peut toujours dire aux types qui
>>> > codent
>>> > "essayez de n'utiliser que du read et du write", mais a mon avis ca ne
>>> > sera
>>> > pas suffisant et rien n’empêchera un type de coder un driver ou un
>>> > autre
>>> > composants avec une methode qui sort des clou, et qui ne sera plus
>>> > compatible avec les autres composants.
>>> > La ou ca part en cacahouète c'est pour le passage d'arguments. Le
>>> > probleme
>>> > ne se présentait pas directement pour l'ancienne archi car toute les
>>> > méthode
>>> > ayant des nom bizarres n'avais jamais d'arguments a passer et donc les
>>> > clients n'avais pas trop de question a se poser.
>>> >
>>> > donc je ne sais pas trop ce que tu en pense, mais il faudrait trouver
>>> > un
>>> > truc pour eviter que ce soit la merde.
>>> > moi j'envisage deux pistes (aucune des deux ne me plais vraiment)
>>> >
>>> > n'autoriser les methodes exotiques que pour les composants qui sont
>>> > mappé
>>> > avec un objet terminal.
>>> > n'autoriser les méthodes exotiques que si elle n'ont pas d'argument a
>>> > passer, pour les autres il y a le read et le write.
>>> >
>>> > voila, je ne sais pas ce que tu en pense.
>>> >
>>>
>>>
>>>
>>> --
>>> Tapé depuis mon clavier
>>>
>>>
>>
>
>