Re: [openplacos-dev] read, write, normalisation des methodes et nouvelle architecture.

[flagos <flagospub@xxxxxxxxx>]

Mais elle a bien une unité non ?

C'est quoi le read de la regule ? C'est pas le read de la measure ?

Le 19 juillet 2011 17:56, miaouf kirsh <miaoufkirsh@xxxxxxxxx> a écrit :
> Oui je sais pas trop comment gerer les regul pour le coup.
> de toute maniere il lui faut une iface a elle (vu quelle peut etre read et
> write)
>
> Le 19 juillet 2011 17:10, flagos <flagospub@xxxxxxxxx> a écrit :
>>
>> Bon ben je suis dacc sur les ifaces, ainsi que les conventions de
>> nommage. Ca me parait pas mal comme ca
>>
>> Pour les order* , j'ai du mal a voir comment ajouter une unité (ou du
>> moins son equivalent chez les sensors) ni si c'est vraiment pertinent.
>>
>> Sinon oui, les regules sont assez interessantes: au niveau de la
>> mesure, elles seront assez permissives tandis qu'au niveau des
>> controles, elles seront deja plus strictes (meme si une regule tout ou
>> rien peut attaquer une pwm, (oups un graduateur pardon ;-) ) par
>> exemple). Il va falloir y repenser pour enrichir la syntaxe, autoriser
>> tous les sensors analog.
>>
>> De meme, une regule va présenter une interface de controle de type
>> write sur une interface sensors.analog.temperature.celsuis histoire
>> que les clients sachent que c'est une regule qui s'exprime en celsuis.
>> Or cette interface lui a été heritée par branchement, on ne peut pas
>> la caler en dur dans la regule et faire une regule pour chaque unité,
>> ca sert a rien. Donc la c'est rebelote, un coup de syntaxe magique
>> pour pouvoir gerer ca, nettement moins simple celle la.
>>
>>
>> Le 19 juillet 2011 12:14, miaouf kirsh <miaoufkirsh@xxxxxxxxx> a écrit :
>> > 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
>> >>>
>> >>>
>> >>
>> >
>> >
>>
>>
>>
>> --
>> Tapé depuis mon clavier
>>
>>
>
>



-- 
Tapé depuis mon clavier