tsp-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: [Tsp-devel] flux de commande: CORBA, XML-RPC, SOAP-RPC...


From: DUFRENNE, Yves
Subject: RE: [Tsp-devel] flux de commande: CORBA, XML-RPC, SOAP-RPC...
Date: Mon, 12 May 2003 14:44:59 +0200

Après discussion analogique avec Éric, on en a conclut que le plus open
serait de

1) Faire ce qu'il dit : Plusieurs types de commandabilitée (XML, RPC, Corba)
parlant par l'interface incore "SHM|Queue|..." 

2) Gérer par autocon le(s)quel(s) des protocoles de commande l'on souhaite
compiler en lib dynamiques.

3) Rendre le coté SHM embrayable / Debrayable (surtout pour le débug et le
coté embarqué)
C'est à dire un provider peut intégrer directement la commandabilité RPC,
Corba, XML, ...par son thread principale 
Ou il peut écouter sur l'interface incore, et il faut lancer un autre
process (ou plusieurs) parlant le XXX pour le piloter.

Actions :
- Stef Gal.... : Toi qui a codé le thread RPC, as tu un avis sur la
faisabilité / coût de DVP
- Quel type de I/F incore est portable UBI/Orbit (Linux, solaris, OSF,
LynxOS, VxWorks) => Éric (c'est son idée après tout)
- Qui veut s'y mettre ??? (au moins pour tester le coté (em/de)brayable
d'une incore pour le RPC actuel.

Y++

> -----Original Message-----
> From: NOULARD Eric [mailto:address@hidden
> Sent: Friday, May 09, 2003 12:54 AM
> To: Devel TSP
> Subject: [Tsp-devel] flux de commande: CORBA, XML-RPC, SOAP-RPC...
> 
> 
> 
>       Ben pour le lien de commande asynchrone
> je tenterai bien effectivement XML-RPC.
>       Quoiqu'il en soit je pense qu'il serait souhaitable
> de pouvoir facilement changer ce lien de commande.
>       Je propose la méthode suivante:
> 
>       1) on définit la structure d'une SHM (ou queue de message)
>          par laquelle
>          notre serveur TSP >>>ACTUEL<<< recevra des requêtes
>          asynchrones.
> 
>       2) On peut lancer en plus du TSP provider 'de base' 
>            un processeur de requêtes
>            asynchrone qui recevra les requêtes des consumers.
> 
>       3) On réalise plusieurs processeurs de requêtes:
>            - serveur RPC (comme aujourd'hui)
>            - serveur XML-RPC
>              - serveur CORBA
>              - serveur parlant le Capoeira
>              - ...
> 
>       A noter que le lien socket pour les données est 
>       (pour l'instant) indépendant de tout ça :))
>       Cela constituerai en fait la première partie de l'interface
>         In-Core de TSP avec MOULT avantages
>       dont différents types de communication asynchrone SIMULTANEMENT 
>       possibles. Je veux dire par là qu'on pourrait décider d'offrir
>       au provider une interface RPC+XML-RPC+CORBA sans 
> problème      majeur.
> 
> J'attends vos remarques.
> -- 
> Eric NOULARD
> Syntegra-FR - Toulouse / http://www.syntegra.fr
> E-mail: address@hidden
> Tél: 05 34 60 49 70 
> 
> 
> 
> _______________________________________________
> Tsp-devel mailing list
> address@hidden
> http://mail.nongnu.org/mailman/listinfo/tsp-devel
> 

Attachment: important_notice.txt
Description: Text document


reply via email to

[Prev in Thread] Current Thread [Next in Thread]