Re: RE : [Tsp-devel] demande approbation modifs de TSP core: tsp_requ est_sample.

[Eric NOULARD]

Le but de mon mail est de vous demander
si je peux créer un répertoire

tsp/src/core/common

contenant un certains nombre de choses.

Suite a un début d'implementation de la modif
(request_sample qui renseigne l'answer sample correctement)
je me heurte à ce dont nous avons un peu discuté avec Stéphane sur
l'API java.

Je résume ça en disant qu'il serait souhaitable d'avoir 2 API:

celle qu'on a appelé 'n' qui serait simple à utiliser pour 
coder soit un provider soit un consumer
et la 'n-1' qui serait proche des éléments de specs
sans être liée à un choix d'implem' comme par exemple
d'utiliser les types générés par rpcgen comme type de base.

Dans l'API C, c'est pas trop comme ça pour plein de bonnes
raisons mais j'aimerai préparer le terrain pour un changement
plus profond à l'occasion de ma petite modif:

créer un répertoire src/core/common qui définisse les
fonctions et types de l'API N-1 utilisable à la fois côté provider
et côté consumer.
Il y aura ensuite dans src/driver et src/ctrl les compléments
d'API N-1 pour les consumers et provider ainsi que les API 'N' 
s'appuyant sur les 'N-1'.

Le principe de base des API 'N' etant du 'C orienté objet'
un peu comme ce qui a été fait pour les request_handler
(ou le bb_core.[hc])

genre type toto_t
avec fonctions 'membre' du genre
toto_create(toto_t** this, parm1, parm2) 
toto_method1(toto_t* this);
etc...

Êtes-vous ok pour la création de src/core/common
qui contiendra pour les besoins de la modif simple du
request_sample/answer_sample quelques types et fonctions simplifiant
(rendant plus claire) l'implem' de la modif.

Au passage ça rajoute donc une lib_tspcommon.a également.

Votre avis?
 
Le vendredi 11 mars 2005 à 09:52 +0100, TSP a écrit :
> Je suis d'accord sur la spec d'origine : Il devait bien renseigner tous les
> symbols possibles. Si tu as le temps, vas-y.
> Y++
> 
> PS : Que l'on fasse de l'arbre, du regexp ou autre chose, je pense vraiment
> que le request info (partiel ou non) ne devrait donner QUE les noms et
> deviendrait un request_list. Ensuite de cette requeste liste on pourrait
> relancer le request info pour avoir le type des symboles. 
> 
> 
> -----Original Message-----
> From: Eric NOULARD [mailto:address@hidden 
> Sent: Thursday, March 10, 2005 11:48 PM
> To: Devel TSP
> Subject: [Tsp-devel] demande approbation modifs de TSP core:
> tsp_request_sample.
> 
> 
> 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.
> 
> 
> 
> 
> 
> _______________________________________________
> Tsp-devel mailing list
> address@hidden
> http://lists.nongnu.org/mailman/listinfo/tsp-devel
> _______________________________________________ Tsp-devel mailing list 
> address@hidden http://lists.nongnu.org/mailman/listinfo/tsp-devel