tsp-devel
[Top][All Lists]
Advanced

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

RE: [Tsp-devel] Chti prob de compil


From: Eric.NOULARD
Subject: RE: [Tsp-devel] Chti prob de compil
Date: Thu, 23 Sep 2004 08:10:02 +0200


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





reply via email to

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