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

[Eric.NOULARD]

> De:   address@hidden de la part de PAGNOT, Robert
> Date: lun. 09/05/2005 09:14

> 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 ?


En fait nous avons utilisé tes merveilleuses tables
de hash, sauf que le stockage de la table de hash
prends un peu moins de 1 Go de mémoire :))

On peut certainement trouver un meilleur compromis
temps de recherche/espace de stockage mais le 'vrai' pb
est que c'est le TSP core qui fait aujourd'hui la recherche
dans la liste 'exhaustive' des symboles alors que le GLU
pourrait faire BEAUCOUP mieux pour BEAUCOUP moins cher
suivant les cas.

Par exemple imaginons que je decide que mon GLU valide
ces symboles via une base de données (genre mySQL, postgreSQL
voire une base embarquée en mémoire style SQLite)
j'ai pas envie d'emener toute cette m...e dans le tsp CORE non?

Un autre GLU 'propriétaire' pourrait aller lire/consulter
un fichier de BD mmappé ou que sais-je encore...

Donc déléguer la validation des symboles au GLU me permet
de faire des choses "spécifiques" efficace sans obliger
tout le core TSP à faire pareil.

Maintenant si mon GLU n'est pas malin ben il prendra
l'implem' par défaut qui strcmp la liste de tous les symboles.

En gros je cherche à ouvrir les possibilités car j'ai
le sentiment que

"LA" meilleure solution pour tous n'existe pas [encore]??

Eric

-------- Message d'origine--------
À:      'Eric NOULARD'
Cc:     Devel TSP
Objet:  RE : [Tsp-devel] suggestion de changement GLU/tsp_core [part 2]
Je réponds à la question :



A+

        Robert


-----Original Message-----
From: Eric NOULARD [mailto:address@hidden <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
<http://lists.nongnu.org/mailman/listinfo/tsp-devel>