RE : RE : [Tsp-devel] demande approbation modifs de TSP core: tsp _requ est_sample.

[TSP]

Je suis pour l'API niveau N (simplifié, orienté user) et l'API N-1
(élémentaire, orienté dev)
Pourquoi pas dans src/core/common, je ne suis pas segregastionniste (je sais
même pas comment cela s'écrit), et on peut imaginer de mélanger
provider/consumer.
Mais pourquoi une libtsp_common.a, je ne vois pas le gain ? Ne pourrait on
pas ventiler ces fonctions dans les lib provider et consumer existantes,
cela eviterait de rajouter ENCORE de nouvelles libs ?

Y++


>-----Original Message-----
>From: Eric NOULARD [mailto:address@hidden 
>Sent: Tuesday, March 22, 2005 12:05 AM
>To: Devel TSP
>Subject: Re: RE : [Tsp-devel] demande approbation modifs de 
>TSP core: tsp_requ est_sample.
>
>
>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
>
>
>
>_______________________________________________
>Tsp-devel mailing list
>address@hidden
>http://lists.nongnu.org/mailman/listinfo/tsp-devel
>

important_notice.txt
Description: Text document