RE: [Tsp-devel] Chti prob de compil

[TSP]

Moi ce que j'avais imaginé :

1) Le configure permet de choisir les protocoles : RPC, CORBA, XML, TamTam,
.... Par defaut on tente d'en implementer le maximum sur le host.
2) La lib serveur contient tous les protocoles demandés (le serveur doit
pouvoir écouter pleins de clients differents, et donc autant tout lui mettre
dans une seule lib). Le faire avec plusieurs lib risque d'etre difficile
avec le core qui est commun, et le handler à n protocol fait par HéRiK.
3) Il y a une lib client par protocole: Un client ne va pas s'amuser à
parler corba et rpc. Il choisit un langage, et le serveur n'a qu'a être
compatible. Aux emmerdeurs qui me dirait "Oui mais si le serveur n'a pas ce
protocole la" je leur dis que "tant va la cruche à l'eau qu'à la fin elle me
les brises"

Voila à toi la communauté.

Y++

> -----Original Message-----
> From: Frederik Deweerdt [mailto:address@hidden
> Sent: Thursday, September 23, 2004 12:19 AM
> To: address@hidden
> 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