RE: [Tsp-devel] Chti prob de compil

[TSP]

Après rebouclage avec Eric :

 

On génère  une lib par type de com coté consumer. Chaque client se link comme il le veut.

On génère une lib avec tous les types de com possible (ou une partie par configure) coté provider.

Chaque flux de commande a la bonne abstraction pour pouvoir se plugguer joliment dans le provider.

 

Par fichier de conf on peut décider d'arrêter/redémarrer un type de flux de commande.

On fait cela pour 2 ou 3 flux différents, pour être sur que l'API de plug des commandes est OK.

On peut donc avoir un serveur présent pour plusieurs types : Url genre "xml://myhost.ici.la/StubServer:10"  et "rpc:myhost.ici.la/StubServer:11"

Le tsp-server-num sert de port de base pour commencer la recherche sur un host.

 

Plus tard, quand cela marchera bien, si un courageux en a envie, on pourra même faire des lib dynamiques avec plugin à chaud d'un nouveau type de commandabilité.

Vous pouvez encore réagir/râler à cette proposition.

 

Y++

-----Original Message-----
From: address@hidden [mailto:address@hidden
Sent: Thursday, September 23, 2004 8:10 AM
To: address@hidden
Subject: RE: [Tsp-devel] Chti prob de compil

Mon idée (j'attends donc les remarques)
était que le consumer choisit sa méthode
statiquement (rien ne l'empêche d'en avoir plusieurs)
on ne peut pas penser que tous les consumers TSP connaissent
TOUTES les type de canaux de commandes.

Côté provider (lib en C) on doit pouvoir "activer" ou "désactiver"
ce que j'appelle un "chemin/canal de commande"  lors du configure.
Par défaut c'est RPC actif rien d'autre.

Si tu rajoute un canal de commande il faut que tu regardes
dans tsp/src/core/ctrl/tsp_request.[hc] j'ai prévu
des fonctions d'init, de run et d'arrêt d'un canal de commande
histoire (soyons fou) d'avoir les points d'entrées suffisants
pour charger dynamiquement un canal de commande.

L'aspect dynamique ne me parait pas prioritaire mais ça présenterait
l'avantage que si disons Fred D. a dévéloppé un canal de commande maison
il puisse facilement le proposer à tous ses amis sans que ceux-ci n'aient
besoin de re-compiler leur provider TSP.
En gros je balance le tsp_request_handler_FredD.so à côté du
provider TSP j'envoie un kill -HUP au provider et hop il se mets
à parler le FredD.

Aujourd'hui c'est alpha vu que le seul test que j'ai fait c'est
2 canaux RPC avec un progid différent ces 2 request handler étant
enregistrés statiquement :))

Je serais super content que tu nous fasses un "vrai" 2ième canal
statique.

Si tu fais ça côté provider, coordonnes toi avec Steph. Galles
pour éventuellement tester ça avec un consumer Java
(je pense à XML-RPC et consort c'est peut-être plus simple
 à réaliser le consumer en Javouille).

Et puis si tu fais le dynamique côté provider là je pense qu'on
pourra se prosterner à tes pieds pour services rendus à notre
cause :))




-----Original Message-----
From:   address@hidden on behalf of Frederik Deweerdt
Sent:   Thu 9/23/2004 12:18 AM
To:     address@hidden
Cc:    
Subject:        [Tsp-devel] Chti prob de compil
Lut,

OpenBSD lève un sourcil suspicieux sur client_res.c :) Ci-joint un patch qui lui permet
de retrouver ses petits.
J'avais commencé à me poser des questions sur l'ajout d'un protocole de transport
Corba, XML/RPC ou HTTP avec surcouche maison. Je me demandais si quelqu'un avait
déjà une idée sur l'architecturation de la chose: faut-il développer des libs
tsp client et serveur parallèles à leur cousines RPC?
Elles auraient, j'imagine, le mode opératoire suivant:
Je fais mon server et mon consumer tsp, et je les linke ensuite à la lib de mon choix
rpc ou corba. Et là surgit un problème: un client corba ne comprend que du corba...
Ou alors me fourvois-je et dans ce cas quelqu'un serait-il assez aimable pour éclairer
ma lanterne?

A+
Fred

important_notice.txt
Description: Text document