TR : [Tsp-devel] Sondage : vos idées pou r un'consumer-server Web TSP'

[Eric.NOULARD]

-------- Message d'origine--------
De:     Noulard Eric [mailto:address@hidden]
Date:   ven. 09/01/2004 13:09
À:      'Ibou de Joie'; Frederik Deweerdt
Cc:     'address@hidden'; Yves DUFRENNE (Adresse de messagerie); NOULARD, Eric-Syntegra FR; TARAYRE, Alexandre-Syntegra FR
Objet:  RE: [Tsp-devel] Sondage : vos idées pour un'consumer-server Web TSP'
> De: Ibou de Joie [mailto:address@hidden]
> Date: vendredi 9 janvier 2004 08:59
> À: Frederik Deweerdt
> Cc: Noulard, Eric
> Objet: Re: [Tsp-devel] Sondage : vos idées pour un'consumer-server Web TSP'
>
>
> On Thu, 2004-01-08 at 18:49, Frederik Deweerdt wrote:
> > > Éric a déjà travaillé pour rendre l'API de commande de  TSP compatible
> > > de plusieurs flux d'entrée, mais hélas nous restons RPC. Il  faudrait un

A noter que je n'ai pas fait le travail pour jTSP mais seulement
dans la lib C.

> > > peu de XML-RPC pour le coté Win, et du CORBA pour le coté High-Tech. On
> > > attends toujours un volontaire, la récompense étant cette fois une soirée
> > > karaoké avec un troupeau d'élans.
> > Est-ce que tu as déjà une idée du découpage de la structure des
> > sources/libs (qu'est ce qui est rpc-indépendant ou mettre tout ce qui
> > est rpc-dépendant)?
> Moi je voyais bien une lib client par type de flux de commande, et un
> moyen par le configure de decider le nombre de lib généres :
> Pour moi un  
> client ne parle qu'un langage, à la difference du provider

        Personnellement je pense que pour chaque 'type' de flux de commandes
on devrait avoir un répertoire src/core/<type_de_flux>
aujourd'hui on a src/core/rpc
demain on pourrait avoir src/core/xml-rpc, src/core/corba, src/core/soap etc...
        Le reste doit être <flux_de_commande_indépendant>.
en sachant qu'on a une arbo par langage donc:
on pourrait avoir aussi (pour jTSP):

        src/jcore/tsp/core/xml-rpc etc...

Au moment du configure on choisi d'activer (au niveau de la lib)
AUTANT d'interface de commande que nécessaire via
des --enable-<type_de_commande>

> > D'après ce que j'ai pu voir, le code est fortement couplé à RPC: est il
> > souhaitable de refaire certains trucs (c'est à dire ajouter  une couche
> > entre TSP et sont pourvoyeur de commandes surtout dans l'optique ou
> > aurait en plus un provider CORBA) ou ai-je raté un truc?
> En effet les structs sont issus d'un .x . Je crois que eric
> pensait à un
> convertisseur d'IDL en XLST qui ferait du XML=> XDR/IDL/....

    Oui c'est souhaitable mais il faut le faire.
    Malgré tout on est pas EXTREMENT lié à RPC, il "suffit"
que tsp_datastruct.h arrête d'inclure tsp_rpc.h et qu'il soit
rangé "ailleurs" que dans src/core/rpc mais plutôt
dans src/core/include. D'ailleurs mieux vaudrait l'appeler
tsp_internal_api.h car il y aura à la fois des données et
des protos de fonctions dans ce .h.

        Une fois que c'est fais il faut prévoir
POUR CHAQUE CANAL de COMMUNICATION:

        une méthode de copie-in copie-out des structures/types
"interne" de TSP ceux de src/core/include/tsp_internal_api.h
vers ceux acceptés par le canal de commande. Aujourd'hui
on peut faire du "zero-copie" pour le canal RPC mais on peut
prévoir les wrapper. Et puis aussi appeler les fonctions
de l'api internal dans les fonctions d'interface du canal
de commande concerné.

        L'aspect 'génératif' est un plus qui nous permettrait
justement de générer ces wrappers au lieu des les écrires.
Un collègue (Alexandre TARAYRE) a bien entamé le travail mais
n'a pas le temps de continuer pour l'instant. Vous pouvez aller
piocher sa version de TSP sur (voir mon prochain mail).

        Il faut jeter un oeil dans:

        tsp/src/consumer/xdr_writer et les sous-répertoires
       
        il y a un consumer qui crache dans un fichier au format XDR.
        et il y a le début de l'aspect génération XML + XSL.

        A toi de voir si c'est raisonnable d'essayer de continuer
l'aspect XML + XSL ou si tu te cognes les wrappers XML-RPC
"à la main" et on reprend l'aspect génératif plus tard.
        L'aspect génératif n'est pas forcément aussi simple
qu'il y parait, il est bien avancé mais clairement pas fini.
       
> > Pour la lib xmlrpc, j'ai pensé à
> http://xmlrpc-c.sourceforge.net, est-ce
> > que vous aviez déjà pensé à d'autres choses?
> Euh non, pourquoi pas

        Pas mieux.

> > As tu congelé le troupeau d'élans, puisque le développement de tout cela
> > risque de prendre un certain temps.
> Non ils font encore la nouba dans mon garage. Mais j'ai de quoi les
> occuper avec la table de ping/pong.

A (+-+)