[Top][All Lists]
[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.
- [Tsp-devel] suggestion de changement GLU/tsp_core [part 2],
Eric NOULARD <=