RE : Re : RE : [Tsp-devel] Nouvelle API dans tsp_consummer.h

[eric.noulard]

>De: Stéphane [mailto:address@hidden
>Date: jeu. 06/10/2005 20:06
>À: Noulard,E,Eric,JPEF D; address@hidden
>Objet : Re: Re : RE : [Tsp-devel] Nouvelle API dans tsp_consummer.h
 
>Agur,

>Tout ce que je viens de lire me fait douter...

>Si dans ma session que je charge, j'ai N symbôles dont les noms

ATTENTION camarade si dans la session que tu charges tu connais DEJA
les symboles tu n'as plus besoin de lancer une request_filtered_infos 
compliquée.

Si tu connais DEJA les symboles (chargement de session tu feras):

TSP_request_filtered_infos(.. "simple://minimal"); (pour obtenir freq de base 
notamment)
puis
TSP_request_sample(...)

Tu dois pouvoir construire ta TSP_request_sample avec les données sauvegardées.
En retour tu n'as qu'à vérifier (dans l'answer_sample) si ta requetes est 
toujours valide.

En gros le TSP_request_sample sert à la fois de VALIDATION des symboles demandés
et également de préparation de sample.

>Comment je fais pour les récupérer en une fois ???
>Est-ce que la string "[tutu,arbre,mer,voiture,camion,maison,moto]"
>sera permise ?

Donc on utilisera des TSP_request_filtered_infos compliquées 
uniquement si ON NE CONNAIT PAS les symboles :))

Donc ce n'est typiquement pas le cas d'une session sauvegardée.
De toute façon je n'aurai pas le temps de coder la gestion de requêtes
"évoluées" pour l'instant.

Il n'y aura que :

  TOUT: TSP_request_infos actuel
  MINI: TSP_request_filtered_infos --> base freq, TSP version, ...
  MINI+: Idem MINI + nb_symbol.

Je vous soumets l'API finale ce WE.
Quoiqu'il en soit elle permettra les extensions à tout genre de
fantaisies de filtrage via probablement
un int + une string.

C'est Yves qui a réclamé le int et il n'a pas tort car de cette
façon on pourra plus simplement discriminer le 'type' de filtrage
(sql, regex, list, xpath, ...)

Eric

On Thu, 6 Oct 2005 10:47:47 +0100, <address@hidden> wrote:

>> Date: jeu. 06/10/2005 09:05
>> À: Devel TSP
>> Objet : RE : [Tsp-devel] Nouvelle API dans tsp_consummer.h
>
>> Une remarque :
>> Passer une string pour faire un genre de filtre dans la liste des  
>> variables
>> me plait bien.
>> Surtout qu'un filtre du genre "*TOTO*" qui rends tous les symbols dont  
>> le
>> nom contient la chaine "TOTO" est simple à faire.
>
>> Par contre passer une string "minimal" ou "minimal+" me parait dommage,
>> surtout si un jour on veut demander un tous les symbols qui contiennent
>> "minimal" dans leur nom.
>
>> Je preferais presque un champs en + genre enum ( NOM_PROVIDER,
>> FREQ_PROVIDER, NB_SYMB, REGEXP, ...) qui donne la maniere de comprendre  
>> la
>> string passé en parametre. Ou alors une fonction differente qui donne le
>> nombre et la frequence.
>
> En fait j'en ai dit que la moitié et je suis d'accord
> dans mon esprit la string aura un prefixe qui indiquera 'le type du  
> filtre'
> genre:
>
> simple://minimal
> simple://minimal+
>
> mais aussi (plus tard)
>
> regex://.*toto.*
> sql://SELECT * FROM symbols WHERE PGI > 23 AND TYPE = 'double';
> pgirange://..500
> pgirange://53..102
> xpath://<une_belle expression xpath>
>
> etc...
> [on pourrait vérifier avec TSP_request_feature le type de filtre
>  supporté par le provider]
>
> Dans TOUS les cas la réponse (valeur de retour de l'appel RPC) sera une
> TSP_answer_sample_t qui contiendra les infos demandées, le reste étant
> éventuellement positionné à des valeurs non significatives.
> Pour rappel la structure TSP_answer_sample actuelle:
>
> struct TSP_answer_sample_t
> {
>       int version_id;
>       unsigned int channel_id;
>
>       int provider_timeout;
>       int provider_group_number;
>       TSP_sample_symbol_info_list_t symbols;
>       double base_frequency;
>       int max_period;
>       int max_client_number;
>       int current_client_number;
>       TSP_status_t status;            
>
>       /*unsigned int feature_words[4]; FIXME*/
>       /* TSP_endianity_t data_endianity; FIXME : implementer */
>
>
> };
>
> Mon idée est de limiter au maximum le nombre de structure et de fonctions
> qui traverse le réseau.
>
> Est-ce que ça te va Yves?
> Et les autres votre avis?
>
> Eric
>
>
>
>
>
> _______________________________________________
> Tsp-devel mailing list
> address@hidden
> http://lists.nongnu.org/mailman/listinfo/tsp-devel
>