tsp-devel
[Top][All Lists]
Advanced

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

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


From: Eric NOULARD
Subject: [Tsp-devel] suggestion de changement GLU/tsp_core [part 2]
Date: Fri, 06 May 2005 13:36:05 +0200

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.





reply via email to

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