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

[flagos <flagospub@xxxxxxxxx>]

mmmm effectivement

Le 19 juillet 2011 18:08, miaouf kirsh <miaoufkirsh@xxxxxxxxx> a écrit :
> ben je vois bien l'etat de la regul dans le read.
> sinon je vois pas trop comment la choper avec un write.
> c'est possible mais ca colle pas trop avec le trip read/write
>
> apres on peut imaginer une iface org.openplacos.regul.celcuis etc
>
> Le 19 juillet 2011 17:59, flagos <flagospub@xxxxxxxxx> a écrit :
>>
>> 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
>>
>>
>
>



-- 
Tapé depuis mon clavier