> ben j'ai pas proposé autre chose.
> le truc avec les pin backend c'est que tu sais pas si elle sont pluggé
> deriere
>
> Le 10 août 2011 15:13, flagos <
flagospub@xxxxxxxxx> a écrit :
>>
>> C'est pas du protocole, c'est juste qu'on aurait une pin backend avec
>> plusieurs ifaces dedans
>>
>> C'est pareil qu'en entree, toute l'info est dans l'introspect
>>
>>
>> Le 10 août 2011 15:01, miaouf kirsh <
miaoufkirsh@xxxxxxxxx> a écrit :
>> > en fait, a l'heure actuelle ya pas de check de liens
>> > quand un truc est pas pluggé, on a un truc du style "no method ... for
>> > nilclass"
>> > a priori je dirais solution 1, parce que aller rajouter du protocole
>> > pour un
>> > cas tordu ca saoule ...
>> >
>> > Le 10 août 2011 14:52, flagos <
flagospub@xxxxxxxxx> a écrit :
>> >>
>> >> mmm
>> >>
>> >> J'avoue que dans l'idée, je m'etais dit plutot solution 1 ;-)
>> >>
>> >> Apres, ca peut etre effectivement a gerer, mais pas comme proposé en
>> >> 2. Si par exemple ton composant nous dit qu'il supporte plusieurs
>> >> types d'ifaces en sortie sur la meme pinoche, on peut se demerder pour
>> >> lui en proposer une qui soit dans sa liste et dans celle du composant
>> >> oou il est pluggué.
>> >>
>> >> Comme on garderait le check des liens au debut avec l'introspect.
>> >>
>> >> Le 10 août 2011 14:07, miaouf kirsh <
miaoufkirsh@xxxxxxxxx> a écrit :
>> >> > yop
>> >> > j'ai codé un bout de VP
>> >> > j'ai eu la bonne idée (ou pas) d'emuler dans vp de vrai capteurs
>> >> > (LM335
>> >> > pour
>> >> > la température et HIH3610 pour l'humidité) histoire
>> >> > d'utiliser derrière des
>> >> > composants moins bateau.
>> >> > le HIH3610 a une compensation en temperature, et la je tombe sur un
>> >> > cas
>> >> > interessant ou la datasheet donne une compensation pour une
>> >> > température
>> >> > en
>> >> > °C et en °F
>> >> > si on veut implémenter les deux types de conversion ( cas tordu ou on
>> >> > veut
>> >> > gerer les composant de température qui n'ont pas implementé la
>> >> > conversion °C
>> >> > <=> °F)
>> >> > on se retrouve avec une entrée qui va appeler soit une sortie soit
>> >> > une
>> >> > autre
>> >> > (2 ifaces différentes) dans sa callback.
>> >> > or, on a pas moyen de savoir laquelle appelé vu que le server va
>> >> > exposé
>> >> > les
>> >> > 2 iface mais que en réalité une seule sera connecté.
>> >> > donc 2 solution :
>> >> >
>> >> > On s'en fout
>> >> > On remonte une erreur du type Openplacos::Error::NoLink quand le
>> >> > composant
>> >> > tente un read/write pour lui signifier que finalement l'iface n'a pas
>> >> > été
>> >> > linké au niveau du server, ainsi le composant pourra caller un rescue
>> >> > et
>> >> > changer d'iface.
>> >> >
>> >> > En fait, je me dit que le 2 sera utile pour d'autre cas, mais ca veut
>> >> > dire
>> >> > qu'on autorise les sortie non linké au niveau du server.
>> >> >
>> >>
>> >>
>> >>
>> >> --
>> >> Tapé depuis mon clavier
>> >>
>> >>
>> >
>> >
>>
>>
>>
>> --
>> Tapé depuis mon clavier
>>
>>
>
>