Re: [openplacos-dev] cas tordu

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


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





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