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

[Eric NOULARD]

Quelques idées sur la générations des 'stub' et autres 'skeleton' de
commande.

1) Aujourd'hui
   On utilise l'IDL ONC-RPC
   et rpcgen pour générer les parties serveurs et client
   
   Du coup comme Fred a dû s'en rendre compte amèrement
   coder un autre canal de commande c'est de l'artisanat
   vu qu'en gros il n'avait pas à sa disposition
   de xmlrpcgen

   En prime on utilise au coeur de TSP les types
   générés par rpcgen (ce qui a été fait par souci de gain
   de temps et c'était bien comme ça à l'époque)

2) Idéalement (à mon avis bien sûr)

   2.a) On spécifie les types et les fonctions TSP
        dans un IDL AD (par exemple un sous-ensemble de l'IDL CORBA)

   2.b) On code des types TSP "à la main" (à voir si on peut mieux
faire)
        ainsi que les fonctions associés "à la mode objet en C"
        (en evitant peut-être d'embarquer à chaque fois les pointeurs de
fonctions dans les types à voir).

   typedef struct tsp_request_sample {
     tsp_sample_list_t  sample_list;
     ...
   } tsp_request_sample_t

   avec son lot de fonctions

   /* constructeur/destructeur */
   int tsp_rqs_create(tsp_request_sample** rqs);
   int tsp_rqs_copy(tsp_request_sample** rqs_dest, tsp_request_sample*
rqs_src);
   int tsp_rqs_destroy(tsp_request_sample** rqs);
 
   /* methods */
   int tsp_rqs_add(tsp_request_sample* rqs, tsp_symbol_t
toBeAddedSymbol);
   int tsp_rqs_remove(tsp_request_sample* rqs, tsp_symbol_t
toBeAddedSymbol);
   int tsp_rqs_nbsymbols(tsp_request_sample* rqs);
   int tsp_rqs_get_symbols(tsp_request_sample* rqs,
tsp_sample_symbol_list* aSymbolList);
   
 etc...
  
     Ceci pour tous les types de base de la spec TSP 
     en gros les mêmes types que ceux définis dans l'IDL tsp_rpc.x
     en mettant de côté les enum qui restent des enum.

   2.c) On code un parser de l'IDL sur lequel on a:
        - Un front-end qui parse
        - +ieurs backend qui génèrent les 'stub' spécifiés 
          on aurait donc 

             - un backend ONC-RPC
             - un backend XML-RPC
             - ... CORBA

        Les backend génère des fonctions qui font:

          a) copie du type TSP vers le type transportable 
               (TSP 'native' type --> TSP network command channel)
          b) copie du type transportable vers type TSP
               (TSP network command channel --> TSP 'native' type)

Evidemment le pb c'est d'avoir à générer des stubs pour, par 
exemple de l'ONC-RPC pour lequel on a déjà rpcgen.
Là je vois plusieurs choix:

  1) s'appuyer sur des outils déjà capables de générer différents stub 
     comme http://www2.parc.com/istl/projects/ILU/
     qui à rajouter ce qui nous manquerait (XML-RPC)

  2) Se coder notre propre parser (par exemple en Java avec ANTLR en
partant de grammaire d'IDL existante
http://www.antlr.org/grammar/1072891676218/idl.g)

     Et on se concentre sur les backend.
     
     2.a) Coder tous les backends et là c'est pénible
     2.b) Coder des backend de traduction 
          par exemple Notre IDL --> ONC RPC IDL
          Et avec ces mêmes backend générer les stub qui manquent
          (ceux pour passer du type TSP 'natif' au type généré par le
compilateur de stub final, dans cet exemple rpcgen)
 

Un collègue avait commencé à essayer de spécifier les interfaces
avec un format XML (au lieu d'un IDL 'classqiue') et de générer les
stub avec des feuilles de styles XSL, ce qui est très fun et portables
mais j'ai le sentiments que c'est plus compliqué qu'avec un vrai parseur
(ANTLR).  J'ai les essais avortés sur mon disque si ça intéresse qq'un.

A très bientôt les amis.
Eric

Le lundi 09 mai 2005 à 10:26 +0200, Frederik Deweerdt a écrit :
> Le 06/05/05 13:36 +0200, Eric NOULARD écrivit:
> > 
> > Je disais donc,
> > 
> [... des bonnes choses ...]
> >
> > Votre avis?
> Ca me paraît bien et c'est à priori la marche à suivre pour tsp_request
> tsp_answer et cie... En tout cas l'ajout de XMLRPC a été facilité par le
> fait d'avoir une interface clean, les points d'entrée core<->commandes étant
> facilement identifiables.
> J'attaquerai bientôt la réécriture du code XMLRPC avec un générateur 
> automatique,
> et je pense en profiter pour jetter un coup d'oeil à tsp_request, answer et 
> leurs
> amis. Si t'as déjà des idées dessus, je suis prenneur de tuyaux :)
> 
> A+
> Fred
> 
> 
> _______________________________________________
> Tsp-devel mailing list
> address@hidden
> http://lists.nongnu.org/mailman/listinfo/tsp-devel
>