RE : [Tsp-devel] suggestion de changement GLU/tsp_core [part 2]

[PAGNOT, Robert]

Je réponds à la question :
... merci à Robert & Fred de donner leur avis sur l'utilisation
de cette "interface objet en C" puisse qu'ils ont eut à la
manipuler pour les request_handler RPC et XML-RPC.

L'implementation GLUE-code/TSP-Request-Handler-RPC que j'ai faite pour le SIF m'a semblé directe car l'API était simple à l'époque - rien à dire donc ... Ceci étant, si tu penses que, avec l'ajout de plein de nouvelles fonctionnalités, l'implementation type "objet" avec des fonctions par défaut te semble plus judicieuse, BANCO donc. C'est Yves qui devra faire la mise à jour de l'appli SIF :))))

Par ailleurs, l'utilisation de TSP dans le module en question est très bestial en termes de nombre de symboles (# 2000), de fréquence (8 Hz) et de changement de conf (on prend tout, on reset tout, avant de recommencer !). A priori, on ne devrait pas avaoir besoin des fonctionnalités supplémentaires.

Question annexe pour ton problème de vérif de la request sample list côté Provider : strcmp est bourrin, non ? Pourquoi pas hacher menu le bazar ?

A+

        Robert

-----Original Message-----
From: Eric NOULARD [mailto:address@hidden]
Sent: Friday, May 06, 2005 1:36 PM
To: Devel TSP
Subject: [Tsp-devel] suggestion de changement GLU/tsp_core [part 2]

Je disais donc,

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

Aujourd'hui chaque provider DOIT implémenter TOUTES les fonctions
GLU (glue_sserver.h), vu qu'un provider et lié statiquement à son
GLU sous-jacent.

Donc je suggère que l'interface GLU soit utilisée par le core TSP
sous la forme de pointeur de fonctions et pas de fonctions
liée statiquement de façon à pouvoir offrir des implémentations
"par défaut" de certaines fonctions.

C'est bêtement une façon de faire de l'héritage + surcharge objet
en C.

Notre glue_sserver.h, doit être adjoint d'un glue_sserver.c
qui offre certaines implémentations par défaut pour les fonctions
GLU.

Chaque provider devra:

Implémenter les fonctions GLU 'mandatory' que l'ont pourrait
laisser statiquement liée, quoique...

Implémenter d'éventuelles surcharges des fonctions par défaut.

Fonctionnement:

0) On crée un 'vrai' GLU_handle_t qui serait plutôt un
   GLU_object_t qui sera une structure qui contiendra des champs
   de données ET des pointeurs de fonctions:

   typedef  struct GLU_object {
     GLU_server_type_t   type;
     char*               name;
     ...
     GLU_get_base_frequency_FP            get_base_frequency;
     GLU_get_sample_symbol_info_list_FP   get_sample_symbol_info_list;
     GLU_validate_sample_symbols_list_FP  validate_sample_symbols_list;
     ...
   } GLU_object_t;

1) GLU_init doit faire son boulot habituel
   On ajoute GLU_fin pour la symétrie.

2) GLU_get_instance prends désormais un GLU_object** en premier
   paramètre et renvoie un int (TRUE/FALSE) c'est le constructeur
   de l'objet "GLU_object"
   On ajoute
   GLU_release_instance pour libérer une instance
   destructeur de l'objet "GLU_object".

3) Quand le coeur TSP appelle le GLU_get_instance il doit
   vérifier si des pointeurs de fonctions de la structure
   GLU_object sont NULL et si c'est le cas fournir
   des implémentations par défaut (si elle existe) ou
   refuser de démarrer si aucune implém' par défaut n'est dispo.

Toutes les fonctions GLU_xxx hors mis GLU_init et GLU_fin doivent
prendre en premier paramètre un GLU_object_t de façon à avoir
une interface objet propre.

Votre avis?

PS: J'aimerai d'ailleurs généraliser ces principes d'interface objet
    à tous les autres 'objets' TSP.
    les tsp_request, tsp_answer etc...
    A noter que c'est déjà le cas pour les TSP_request_handler
    merci à Robert & Fred de donner leur avis sur l'utilisation
    de cette "interface objet en C" puisse qu'ils ont eut à la
    manipuler pour les request_handler RPC et XML-RPC.

_______________________________________________
Tsp-devel mailing list
address@hidden
http://lists.nongnu.org/mailman/listinfo/tsp-devel

important_notice.txt
Description: Text document