Re: RE : [Tsp-devel] Ajout TSP_request_extended_informations

[Erk]

Le 22/03/06, TSP<address@hidden> a écrit :
>
> Salut Eric.
> Je vais donner mon avis sur toutes tes questions existentielles dans un seul
> message, pour aller manger + vite...

Ben j'espère que l'apétit était bon.

>
> 1) Extended_informations :
> ===========================
> Ton approche m'a l'air générique, même un peu trop. J'ai peur que cela
> rajoute beaucoup de travail coté client, alors que cela pourrait sans doute
> se commonaliser en dessous dans la libtsp.

On peut c'est clair mais est-ce bien nécessaire...

> Surtout que le besoin en unité, commentaire, nombre de dim et taille des
> dims m'a l'air super basic.

A première vue je suis d'accord avec toi mais...
ça fait quand même 3 ans qu'on fonctionne sans
et pour l'instant ça n'a pas géné beaucoup de monde :)))

> J'aurais donc plutôt vu une structure d'infos par pgi du type
> {
>         char *unit  = "Kg"
>         char *comment "J'ai grossi"
>         int nb_dims = 3
>         int tab_dims[] = { 90, 60, 90 }
>         /* Après on peut imaginer un truc d'extension comme tu le propose */
>         int nb_extensions = 2
>         CoupleValueName_T tab_ext[] = { { "Music", "Funk" }, { "TSP", "Trop
> Super Protocol pour le P2P" } }
> }

C'est ce que je voulais éviter mais je vois pourquoi ça te tente.
Mon idée était également que la récupération/manipulation simple de ces
informations étendue se ferait par une API qui n'a pas besoin de "traverser"
le canal de commande (donc pas [trop] de structure en plus dans le .x).

Je pensais par exemple à une API du genre:

const char* TSP_ssei_get_unit(TSP_sample_symbol_extended_infos_t extInfos);
const char* TSP_ssei_get_comment(TSP_sample_symbol_extended_infos_t extInfos);
nb_dims TSP_ssei_get_rank(TSP_sample_symbol_extended_infos_t extInfos);
etc...
+ les versions génériques:

int TSP_ssei_get_NamedItemAs_int(TSP_sample_symbol_extended_infos_t
extInfos, char* name, int* outvalue);
int TSP_ssei_get_NamedItemAs_double(TSP_sample_symbol_extended_infos_t
extInfos, char* name, double* outvalue);
etc...
ainsi que des fonctions de tests élémentaires:
int TSP_ssei_get_nbNamedItem(TSP_sample_symbol_extended_infos_t extInfos);
int TSP_ssei_isPresent_NamedItem(TSP_sample_symbol_extended_infos_t
extInfos, char* name);
const char* TSP_ssei_get_NamedItemValue(TSP_sample_symbol_extended_infos_t
extInfos,char* name);


> Après que tu le demandes sur une liste de PGI, ou alors comme les
> request_infos classique pour moi c'est pareil.

Le gros avantage de la liste de PGI c'est comme pour l'async_read/write
c'est que côté provider on a pas besoin de revalider le symbole.

On peut obtenir les PGI via une request_infos préalable ou même une
request_sample.

>
> 2) Les tableaux
> ===============
> Je n'ai rien contre le codage en mono-dimension, je pense même que ce sera +
> simple pour le datapool et la gestion mémoire.

C'est aussi pour ça que je préfère le mono-dimension.
Et également parce que l'arrangement mémoire du multi-dim est une affaire
de convention donc laquelle choisir?
On peut largement imaginer un provider avec des données arrangées
en mémoire pour du Fortran et un consumer en C.
Qui ferait la/les transpositions?

> Ce que je ne vois pas encore
> c'est son usage coté lib client. La fonction GetSample devra-t-elle donner
> chaque éléments du tableau, ou bien un gros machin qui sera déplié à la main
> coté utilisateur ?
> Remarque la question se pose aussi pour les types string, unsigned int,
> ....
> Il va falloir que je réfléchisse mieux à la question.

Je suis d'accord je dois encore browser du code également...

Je fais un mail à part pour l'impact des tableaux et du multi-type
côté datapool et autre ringbuf consumer/provider.

--
Erk