[Tsp-devel] suggestion de changement GLU/tsp_core [part 1]

[Eric NOULARD]

Salut à tous,

J'aurais quelques suggestions de changement dans l'API et 
le mode de fonctionnement entre le TSP core et le GLU provider.

Aujourd'hui nous avons 1 .h (./src/core/ctrl/glue_sserver.h)
qui contient le prototype et la doc des fonctions à 
implémenter pour chaque nouveau provider.


J'aimerai:

1) Rajouter (au moins) une fonction à l'API.

2) Changer la façon dont fonctionne "l'enregistrement" des fonctions
   "GLU_*" dans le core TSP.


1) Ajouter (au moins) une fonction à l'API
   Dans mon pb récurrents de provider avec "what millions de symbols"
   je suis tombé récemment sur un pb simple mais énervant.

   Disons que mon provider à 1 000 000 de symboles et disons
   que je sois patient (et chanceux) et que la request_infos passe sans 
   pb.
   J'envoie une requete de sample de 20 symboles et je sample apparement
   sans souci cool :))
   Maintenant j'envoie une requête de sample de 3000 symboles et là 
   plus de sample :((( avec en prime un "RPC request timeout".

   Vous voyez ou je veux en venir...
   Voilà: 
   Le provider mets tellement de temps (+de 2min) à valider la requête
   de sample pour vérifier les symboles que l'appel RPC part en timeout
   [réglé par défaut à 1 minute 
    src/core/include/tsp_const_def.h::ligne 240
     #define TSP_RPC_CONNECT_TIMEOUT 60
   ]

   Il mets un temps infini car il se fait une double boucle dont
   l'ordre de grandeur est nb_symbol_provider * nb_symbol_request_sample
   dans mon cas: 3 000 000 000, si si 3 milliards de strcmp !! :<<<
   [le code est là:
    src/core/ctrl/tsp_session.c:
    TSP_session_get_symbols_global_index_by_channel(...)
   ]

   Donc là je me suis dit que 
        1) s'arranger pour concevoir une request info avec dépliage
            successif ne suffisait pas, voire que c'est "annexe" face
            au pb de validation des requêtes de sample par le provider.
        2) Qu'on était passé à côté du fait que celui qui sait
           COMMENT valider EFFICACEMENT les symboles ce n'est pas le
           core TSP mais bel et bien le GLU.

Donc je souhaiterais ajouter une fonction

int  GLU_validate_sample_symbols_list(GLU_handle_t h_glu,
                                      TSP_sample_symbol_info_list_t*
                                      symbol_list);

à l'I/F GLU histoire que si un provider avec un nombre de symboles
conséquents sait comment il peut valider les symboles plus efficacement
qu'avec une double boucle il le fasse.

cette fonction renvoie -1 si la validation de la liste échoue et
0 si tout va bien. Dans tous les cas la TSP_sample_symbol_info_list est 
renseigné avec le provider global index qui va bien pour
chaque symbole demandé ou -1 si le symbole n'existe pas.


Comme j'ai dit "au moins 1" c'est parce que je pense que la 
"gestion" des symboles doit être faite par le GLU qui est 
le seul à savoir le faire efficacement. Toutefois on pourrais
fournir des "implémentations" par défaut de certaines fonctions GLU.
d'où ....

2)Changer la façon dont fonctionne "l'enregistrement" des fonctions
   "GLU_*" dans le core TSP.

Finalement je fait un second mail pour ça car celui-là est déjà trop
long :))

Eric