[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Tsp-devel] URL pour Canal de Communication
From: |
PAGNOT, Robert |
Subject: |
[Tsp-devel] URL pour Canal de Communication |
Date: |
Thu, 23 Sep 2004 13:18:14 +0200 |
Beware
of my modifications ...
Je
touche aux mécanismes de request handler actuellement pour pouvoir générer et
récupérer un URL associé à chaque canal de commande.
Premier commit (RPC only) prévu en fin de PM
!!!!
Bob
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
[Prev in Thread] |
Current Thread |
[Next in Thread] |
- [Tsp-devel] URL pour Canal de Communication,
PAGNOT, Robert <=