Re: [openplacos-dev] cas tordu

[flagos <flagospub@xxxxxxxxx>]

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