Re: [Tsp-devel] XML au secours des IDL

[Vivian Larrieu]

 Bonjour à tous,

la philosophie multi-canaux de commande me plait beaucoup.

J'ai trouvé ce projet sur le Net : http://www.cs.utah.edu/flux/flick/

Il décompose la génération des stubs client et serveur en trois étapes.
 1. La conversion du fichier de définition (.idl, .x, ...) en un format 
générique.
 2. La conversion du format générique et pré-code
 3. La transformation du pré-code en code suivant le modèle choisit (RPC, 
Corba-C, Corba-C++, ....)

Cela peut-être un point de départ, nous évitant en plus de coder la partie 
client/serveur CORBA.

  Vivian

At 08:21 18/06/2003 +0200, Eric NOULARD wrote:

> Bonjour a tous,
>
> Dans l'envie frenetique d'ajouter moult canaux de communication a TSP
> un petit loup est sorti du bois.
> Si on imagine qu'on peut desormais envoyer des requetes TSP asynchrones
> via divers canaux (RPC, CORBA, XML-RPC, SOAP...) se pose le probleme
> de spécifier dans les differents IDL (Interface Definition Language)
> les interfaces de TSP (types et fonctions).
>
> Aujourd'hui tout est fait via tsp/src/core/rpc/tsp_rpc.x
> ou est specifié l'interface TSP dans l'IDL ONC-RPC.
> Apres un petit coup de rpcgen on inclut le core/rpc/tsp_rpc.h genere
> dans core/rpc/tsp_datastruct.h.
> Ce dernier est inclut a tire larigot dans le reste de l'arbo.
>
> Il y a 1 mauvais point c'est qu'on utilise en interne de TSP
> des structures issue de RPCGEN. C'était toutefois raisonnable tant
> qu'on ne faisait que du RPC.
> Il y avait 1 bon point, le codage des requetes RPC sont faites SANS COPIE.
>
> Aujourd'hui l'architecture multi-requete asynchrone est prete
> (bo, alpha vu le niveau de test et jusqu'a preuve du contraire :)
> et on peut demarrer plusieurs handler de requetes RPC (j'ai teste avec 2)
> qui cause au MEME provider. (j'expliquerai l'archi dans un autre mail)
>
>
> Demain si j'ajoute un handler de requete CORBA (ben oui c'est beau CORBA)
> je dois:
>
>         1) trans-crire tsp_rpc.x dans tsp_rpc.idl (IDL CORBA)
>         2) generer les stub et skeleton (appelons ca corbagen
>            pour rappeler rpcgen)
>         3) Me coltiner les recopies de structures TSP 'internes'
>            celle definies dans core/rpc/tsp_datastruct.h
>            vers celle generees dans l'étape précédentes.
>
>
> Les points 1 et 3 me déplaisent.
> 1 me deplait car en cas d'ajout/changement a l'interface TSP
> TOUS les fichiers IDL sont a mettre a jour manuellement.
> 3 me deplait pour le côté manuel mais également parce si il
> me prend de generer un TSP (via configure) avec SEULEMENT
> un TSP request handler CORBA, il me faut rpcgen!!
>
> Je propose la chose suivante:
>
> on ecrit un IDL TSP en xml (cf tsp_rpc.xml/tsp_rpc.dtd)
> on ecrit autant de feuille de style XSL qu'on a d'IDL a genere
> disons:
>         c_datastruct.xsl       ---> produit tsp_datastruct.h
>         oncrpc.xsl             ---> produit tsp_rpc.x
>         corba.xsl              ---> produit tsp_rpc.idl
>
>
> Du coup les structures internes de TSP ne dépendent QUE de notre IDL
> qui est 'manipulable' car XML.
>
> On peut generer autant d'IDL qu'on veut a partir de notre fichier
> XML et je pense (mais je suis un bete débutant XSLT)
> assez simplement.
>
> A NOTER QU'IL FAUDRA ECRIRE LES FONCTIONS DE COPIE DES
> STRUCTURES C vers celles utilisees par les stub/skeleton generees
> par les generateurs idoines.
>
> Ci-joint une ebauche avec quelques fichiers joints.
>
> Toutes les remarques sont les bienvenues y compris l'existence
> d'autres solutions multi-IDL que j'aurai raté.
>
>
>
> _______________________________________________
> Tsp-devel mailing list
> address@hidden
> http://mail.nongnu.org/mailman/listinfo/tsp-devel