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

[miaouf kirsh <miaoufkirsh@xxxxxxxxx>]

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