Re: [Tsp-devel] tsp_request_filtered_informations == OK

[Eric NOULARD]

Le vendredi 28 octobre 2005 à 18:30 +0200, Stéphane a écrit : 
> Bonjour à tous,
> 
> Je souhaiterais avoir quelques précisions sur les APIs.
> Voilà un bout de code de GDisp+ dans le thread qui démarre
> les divers samplings (j'ai viré tous les codes de retour mais
> ils sont bien gérés) :
> 
> TSP_consumer_request_sample(provider->pHandle,
>                              &provider->pSampleList);
> 
> TSP_consumer_request_sample_init(provider->pHandle,
>                                   (TSP_sample_callback_t)NULL,
>                                   (void*)NULL);
> 
> while (kernel->samplingThreadMustExit == FALSE) {
> 
>     TSP_consumer_read_sample(provider->pHandle,
>                              &sampleValue,
>                              &sampleHasArrived);
> 
>     ...etc...
> 
> }
> 
> TSP_consumer_request_sample_destroy(provider->pHandle);
> 
> 
> Question 1 :
> La structure 'provider->pSampleList' contient un tableau de structures
> contenant elle-même un nom, un index, une phase et une période.
> Tous les champs doivent-ils être renseignés ?

Les champs nom, phase et period DOIVENT etre renseigné
le nom est la clef qui permettra au provider de dire
si il connait ou nom ce symbole.
la periode ben oui puisque c'est ce qui te permet d'echantillonner
MOINS vite que la frequence de base du provider.
Si period == 1 alors TOUTES les valeurs que le provider peut fournir
Si period == 2 alors le consumer reçoit 1 valeur sur 2 dispo côté
provider
etc...

la valeur max de 'period' acceptable pour un provider est
variable mais je détaillerais ça une autre fois.

> Je parle surtout de l'info 'index' qui est, je crois, l'index dans la
> table globale des symboles du provider.

Exact ceci est une valeur de sortie.

> Quand je charge une configuration from scratch, je dois en premier lieu
> demander tous les symboles du provider pour trouver les index des symboles
> de la configuration. Correct ?

index = pgi ou Provider Global Index, c'est une info provider 

C'est bizarre mais non tu t'en fous, seuls les nom, period et phase
sont nécessaires, d'ailleurs le pgi est susceptible de changer
entre 2 TSP_request_open, voir entre 2 request_sample (même
si ce n'est pas le cas aujourd'hui).
En tous cas ce n'est pas une info a sauvegarder dans un fichier
entre 2 run car si tu redémarre ton provider et emet LA MEME
request_sample tu peux chopper des pgi totalement différents.

> Je pense que j'ai faux quelque part car c'est pas logique de demander tous
> les symboles avant d'en choisir quelques uns, non ?
Ben oui mais bon on manque un peu de doc :))
Si tu as un doute regardes le code de gdisp
cf fichier gdisp_main.c
Gdisp est moche (à côté de gdisp+ s'entend) mais le code
de gdisp_main est correct, mieux vaut ne pas trop regarder les
autres fichiers toutefois :))

> 
> Question 2 :
> J'ai lu les e-mail précédents un peu en diagonale. A quoi
> servent les APIs suivantes :
> 
> TSP_consumer_request_filtered_information
A obtenir des informations "filtrée" c'est à dire un sous ensemble
éventuellement vide de la liste des symboles du provider.

Relis ce mail jusqu'au bout il est pas long
http://lists.nongnu.org/archive/html/tsp-devel/2005-10/msg00018.html

> TSP_consumer_print_invalid_symbols

C'est une manière simple d'afficher sur la sortie standard 
les symboles inconnus du provider.

Dans ton cas tu souhaiteras surement faire qqchose de mieux
à savoit afficher toi-même les nom des symboles inconnus du provider.
En simple  après l'appel

TSP_consumer_request_sample(provider->pHandle,
&provider->pSampleList);

les éléments de la liste  &provider->pSampleList voient
leur champs index renseignés avec un entier positif
si le symbol a été reconnu et accepté et un entier
négatif si:
   * le symbol est inconnu
   * la requete concernant ce symbol
     ne peut être satisfaite period trop grande, phase trop grande.

> 
> Peut-être que quelqu'un devrait tenir à jour un exemple de
> sampling typique avec l'utilisation de toutes les APIs...
> 
Ben oui je suis d'accord il faut un programmer"s guide
mais maintenant que OO 2.0 est sorti on va pouvoir s'y mettre
en Open Document :))
A noter toutefois que la documentation doxygen n'est pas
si mauvaise que ça. (il faut que doxygen (www.doxygen.org) soit installé bien 
sûr)

pour la générer:
cd tsp/src/doxy/
make
ensuite ouvrir l'index de l'aide
tsp/doc/html/index.html 
avec ton navigateur favori.

> 
> Question 3 :
> Mon fichier de sauvegarde de la configuration est un fichier XML.
> Voulez-vous '.xml' comme extension, ou alors '.gdpc' (alias
> 'GDisP+ Configuration') vous va. Cela permet d'isoler les fichiers
> plus facilement.

Comme tu veux :)) 
Par contre concernant ce genre de fichier c'est souvent souhaitable
qu'un champ de version du format de fichier soit présent et obligatoire
dès le début du fichier de façon à faciliter les évolutions et
les MAJ auto entre différentes version (du format de fichier et pas
nécessairement de l'application qui le lit).