Re: [Tsp-devel] Construire une liste de sample

[Eric Noulard]

Le 14/03/07, Yves DUF<address@hidden> a écrit :
> Bonjour à tous & toutes.
>
> Ma problématique est la suivante: Developper un consumer TSP, qui ne demande
> pas la liste globale de tous les symboles des providers, mais qui sache
> demander une sous liste de symboles.

C'est raisonnable mais quel est ton critère de "sous-liste"?

Les n premiers?
Ceux qui sont des tableaux?
Ceux qui sont des int?
La tranche  p + p+n ?

>  Hors il semblerait qu'il soit facile de construire une liste de sample avec
> TSP_SSI_initialize_request_minimal, mais du coups je force
> ma demande pour des paramètres en double.

Tout d'abord une précision  SSI   = Sample Symbol Info
                                        SSIL  = Sample Symbol Info List

Donc on ne construit pas de "LISTE" avec TSP_SSI_initialize_request_minimal
mais on remplit "seulement" une structure SSI avec des valeurs par défaut
"raisonnables" en fournissant à l'API le strict necéssaire pour inclure
ce SSI à  une request sample à savoir:

- le nom du symbole
- la periode

Le fait de "forcer à TSP_TYPE_DOUBLE est pour
garder une compatibilité (au niveau source)
la plus simple avec le TSP 0.7.x qui était mono-type = DOUBLE.

Maintenant:
TSP_SSI_initialize_request_minimal(mySSI
                                      name                              
                                       period);
mySSI->type = TSP_TYPE_UNKNOWN;

fonctionnera TRES bien et ce n'est pas compliqué.
Maintenant je suis près à accepter un bug / change request
pour que TSP_SSI_initialize_request_minimal positionne
le type à TSP_TYPE_UNKNOWN.


> Donc ma question est la suivante : comment construire une
> TSP_sample_symbol_info_list contenant les symboles que je veux mettre en
> acquisition, mais sans savoir initialement leur type et leur dimension, et
> sans demander l'ensemble des symboles au provider !

Dans une SSIL destinée à être intégrée à une request sample
les SEULs informations à renseigner sont:
      - name
      - period

Les autres champs de SSI doivent avoir des valeurs par défauts
(du genre TSP_TYPE_UNKNOW) pour que le provider sache
qu'on est en mode "découverte". C'est le but de l'API
TSP_SSI_initialize_request_minimal de remplir le SSI avec les
valeurs par défaut idoine.

D'ailleurs côté provider c'est le GLU et son API get_pgi qui
"complète & valide" la SSIL contenue dans la request sample.
En fait le GLU cherche le symbol avec "name" puis appelle
GLU_validate_sample_default qui complètera les infos manquantes
et/ou vérifiera qu'elles matches.
Le code de GLU_validate_sample_default (src/core/ctrl/tsp_default_glu.c)
devrait être limpide sur son comportement.

Si j'ai été clair et si j'ai bien compris votre pb n'est
peut-être toujours pas résolu car:

1) soit vous voulez que le provider vous fournisse une sous liste de
   sa liste complète de symbole et là c'est la request_filtered qu'il vous
   faut (quitte à implémenter un autre filtre que SIMPLE, ce qui n'est
   pas compliqué du tout)

> PS:  On a bien une solution de contournement avec le request_filtered, mais
> je ne vois pas pourquoi il faille donner autre chose que les noms pour avoir
> les symboles.

2) Soit votre consumer connait les noms des symboles qu'il veut et là
   c'est très simple, pour chaque symbole de votre liste:

TSP_SSI_initialize_request_minimal(mySSI
                                      knownName                         
                                       period);
mySSI->type = TSP_TYPE_UNKNOWN;

> Je vous joints le message de Sarah pour plus de clareté.

D'après la suite je pense que c'est 2) votre solution.

> ===========
> à l'appel téléphonique d'hier, j'ai regardé les différentes requêtes TSP
> ainsi que quelques exemples de consumers (autre que client.stdout).
> A ce propos , j'ai les remarques suivantes:
>
> Comme nous l'avons vu ensemble hier, pour utiliser correctement la requête
> TSP_consumer_request_sample(), il faut initialiser la structure
> TSP_sample_symbol_info_list*. Celle-ci ne peut pas être initiliasé comme
> dans le client.stdout par la méthode
> TSP_SSI_initialize_request_minimal() car elle impose le
> type TSP_double.(voir TSP_common_ssi.C) .Pour l'EIF TSP, il faut donc
> utiliser la méthode TSP_SSI_initialize_request_full() qui
> nécessite la connaissance du type et de la dimension de chaque symbole.
>
> Or pour connaitre ces deux informations, une solution serait de réaliser une
> requête TSP_consumer_request_filtered_information()avec
> SIMPLE+le nom du symbole suivi de la requête TSP_consumer_get_information()
> pour récupérer les informations du symbole (type+dimension).Ceci serait à
> faire sur tous les symboles demandés par l'utilisateur.
>
> De ce fait, cette solution permet d'avoir une connaissance des symboles
> fournis par le provider et ne nécessite plus la requête
> tsp_consumer_request_sample() pour verifier  la présence des symboles dans
> le provider.( à faire actuellement dans TSP_PROG)


--
Erk