Re: [openplacos-dev] cas tordu |
[ Thread Index |
Date Index
| More lists.tuxfamily.org/openplacos-dev Archives
]
- To: openplacos-dev@xxxxxxxxxxxxxxxxxxx
- Subject: Re: [openplacos-dev] cas tordu
- From: flagos <flagospub@xxxxxxxxx>
- Date: Wed, 10 Aug 2011 15:13:00 +0200
- Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :content-type:content-transfer-encoding; bh=g4QCtFpQJnm6u+kKMsAJ7u3xpNJmsXHqYyHpX+Po+Zs=; b=rFsjM/wK+xNxuuKeZFpJ8BakyiuV0CB3D2i9DkpHmRs5DSCC5Nc3XOJxszV5gs3B8j EWBVC4HzgC5FCPW8Y84VrnFxAAyYw72pdwGNwHSX+209aLnUZv++DUA5uyFg+AT8ZtKu k3i4cUFQ97frkirieR5LEQ4M36TpXxSQBgwAs=
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