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

[ Thread Index | Date Index | More lists.tuxfamily.org/openplacos-dev Archives ]


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





Mail converted by MHonArc 2.6.19+ http://listengine.tuxfamily.org/