[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: [Tsp-devel] Chti prob de compil
From: |
TSP |
Subject: |
RE: [Tsp-devel] Chti prob de compil |
Date: |
Thu, 23 Sep 2004 13:53:19 +0200 |
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++
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
- [Tsp-devel] Chti prob de compil, Frederik Deweerdt, 2004/09/22
- RE: [Tsp-devel] Chti prob de compil, Eric.NOULARD, 2004/09/23
- RE: [Tsp-devel] Chti prob de compil, PAGNOT, Robert, 2004/09/23
- RE: [Tsp-devel] Chti prob de compil, TSP, 2004/09/23
- RE: [Tsp-devel] Chti prob de compil,
TSP <=
- RE: [Tsp-devel] Chti prob de compil, Eric.NOULARD, 2004/09/23