tsp-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Tsp-devel] demande approbation modifs de TSP core: tsp_request_sample.


From: Eric NOULARD
Subject: [Tsp-devel] demande approbation modifs de TSP core: tsp_request_sample.
Date: Thu, 10 Mar 2005 23:48:07 +0100

J'ai une petite demande d'autorisation de modif à faire
à la communauté TSP :))

l'API 

answer_sample_t tsp_consmer_request_sample(requested_symbols)

devait si mes souvenirs de specs sont bon TOUJOURS renvoyer
une answer_sample renseignée au maximum,
aujourd'hui si un symbol n'est pas reconnu par le provider
le consumer sait qu'il y a 1 symbole de pas reconnu mais
il ne sait pas lequel, que que la liste de symboles
contenue dans l'answer_sample dans ce cas est vide.

J'aimerais implémenter 
(c'est pas bien long mais je voudrais votre avis)
ce que je pense être la spec initiale (mais je peux me gourrer)
A savoir TOUJOURS remplir l'answer_sample avec TOUT
les 'requested_symbols', et positionner un status global 
comme c'est fait actuellement

Si le status dit "pb de sample non reconnu' on puisse
aller chercher dans l'answer sample lequel ou lesquels des symboles
est inconnu du provider.

Ma solution serait de positionner le provider_global_index des symboles
en erreur à -1.

Maintenant pourquoi:

Parce que les consumers 'user friendly' QUI ne voudraient pas faire
un request_info (et là vous savez déjà pourquoi) 
pourraient simplement envoyer leur requête de sample et soit la corriger
soit indiquer par un message explicite le/s symbole/s inconnus.

Aujourd'hui c'est ce que fait l'ascii_writer mais en faisant:

1) je parse mon fichier de conf pour constituer la request_sample
2) request_open
3) request_infos
4) validation autonome de la request_sample préparé par rapport
   à la liste reçue de request_infos
5) on dégage les symboles inconnus de la request sample
   [en indiquant un message à l'utilisateur]
6) on envoie la request_sample corrigée.

C'est un comportement qui plait pas mal [aux utilisateurs], 
même si l'implémentation actuelle souffre de la request_infos qui tue :)

A noter que ça permettrait de corriger un défaut majeur de gdisp
qui se borne à dire
>>>
WarninG||tsp_consumer.c##TSP_consumer_request_sample##958: Provider
symbols error
Error while asking for TSP symbols session on host ''
>>>

quand un symbole du fichier de conf n'est pas reconnu du provider
(à cause d'une typo dans le fichier de conf :))

La méthode actuelle consiste à démarrer le provider avec
STRACE_DEBUG=3 
et à ce moment là on a:
>>>>>
   Info||tsp_provider.c##TSP_provider_request_sample##407: Consumer No 0
asked for 29 symbols
   Info||
tsp_session.c##TSP_session_get_symbols_global_index_by_channel##631:
Unable to find symbol 'aSymbol2'
>>>>>

Bon evidemment ça marche mais bon...vous voyez ce que je veux dire.







reply via email to

[Prev in Thread] Current Thread [Next in Thread]