Re: [Tsp-devel] [LONG] Cohabitation xmlrpc - rpc

[Eric NOULARD]

Le samedi 20 août 2005 à 01:34 +0200, Frederik Deweerdt a écrit :
> Kaixo[1] liste,
> 
> Aujourd'hui il n'est pas possible de faire cohabiter dans le même executable
> TSP un canal commandes rpc et un canal commandes xmlrpc. C'est du au fait
> que tsp_consummer.c utilise l'API de tsp_client.c avec TSP_remote_open_server,
> TSP_remote_close_server notamment (liste complete plus bas). Ces deux 
> fonctions, 
> entre autres, étant présentes dans xmlrpc/tsp_client.c et rpc/tsp_client.c, 
> on ne peut pas linker un même client (client_stdout.c par exemple) avec les 
> deux "librairies" en même temps.
> 
> Pour pallier à cela, on choisit actuellement _à la compilation_ le transport
> à utiliser, rpc par défaut et --enable-xmlrpc compile pour... bon, vous avez
> compris :)

Yep et c'est de ma faute car en réalisant/concevant le multi-protocole
côté provider j'ai bêtement oublié le côté consumer en postulant
peut-être un peut hâtivement qu'un consumer ne serait pas
multi-protocole, c'est une erreur :))

> 
> Le but, afin de se raprocher de la domination mondiale,  serait de pouvoir 
> choisir 
> le transport en fonction du protocole que passe l'utilisateur à la ligne de 
> commande 
> ou a son appli GTK 3.0 ;).

ou à défaut /etc/tsp/tsprc ou tout autre .ini, base de reg..tre....
quand TSP sera un composant standard de nos systèmes préférés :))
Mégalomanie quand tu nous tiens...

>  Pour cela je me propose:
> 
> - de refaire le code de parsing URL, pour être compatible std66 alias rfc 3986
> sur les URI (Dans la version que j'ai écrite actuellement, j'utilise les 
> regexp 
> POSIX, y a-t-il une contre-indication à ce sujet sur les plate-formes 
> vénérables 
> que nous supportons?). Les nouvelles URLs auraient la forme suivante:
> protocole://hostname[:port]/server_name#server_instance

Ca je suis 100% POUR avoir un comportement standard.

D'ailleurs je remets un bout de mail précédent qu'on avait eu en privé
avec Duf et que j'aurais dû balancer sur la liste...

[...]####################################################
Pour l'URL je pense que le numéro n'a de sensue pour le protocole
TSP URL format is defined by <PROTOCOL://HOST/SERVER:PORT>
        PROTOCOL   if omitted, is defaulted to 'rpc'
        HOST       if omitted, is defaulted to 'localhost'
        SERVER     if omitted, find any TSP server name
        PORT       if omitted, find first TSP server number

Un "port" XMLRPC et un port "RPC" voire un port "corba"
n'ont peut-être rien à voir entre eux donc c'est pas bien
grave.

Concernant CORBA on a la notion (au moins dans JacORB)
de corbaloc pour trouver un service:

corbaloc::<host>:<port>/<servicename>
par exemple
corbaloc::192.168.0.1:33333/NameService

du coup le port est réellement un port tcp.
D'un autre côté nous on pourrait étendre/transformer nos URLs en
<PROTOCOL://HOST:PORT/SERVER:INSTANCE>

voire se pencher carrément sur les RFCs:
ftp://ftp.rfc-editor.org/in-notes/rfc3508.txt (URL)
ftp://ftp.rfc-editor.org/in-notes/std/std66.txt (URI, URL et URN)

[...]####################################################

> 
> - d'introduire une structure du type :
> 
> TSP_client_operations rpc_client_ops = {
>     .TSP_provider_information = TSP_provider_information,
>     .TSP_remote_open_server = TSP_remote_open_server,
>     .TSP_remote_close_server = TSP_remote_close_server,
>     .TSP_get_server_max_number = TSP_get_server_max_number,
>     .TSP_request_open = TSP_request_open,
>     .TSP_request_close = TSP_request_close,
>     .TSP_request_information = TSP_request_information,
>     .TSP_request_sample = TSP_request_sample,
>     .TSP_request_sample_init = TSP_request_sample_init,
>     .TSP_request_sample_destroy = TSP_request_sample_destroy,
>     .TSP_protocol = TSP_protocol,
> };
> Rassemblant les pointeurs de fonction de l'API cliente

Je suis OK mais j'aimerais bannir les mots clients/serveur
de TSP en restant à consumer/provider.

TSP EST client/serveur mais c'est vraiment un point de vue
"codage implémentation" d'un point de vue conceptuel c'est
plutôt consumer/provider.
Même si ça existe pas aujourd'hui 
(parce ce n'est pas encore  utile) on peut coder un canal
TSP par dessus le blackboard pour lequel différentes parties
d'une même applis seraient consumer/provider les unes des autres
et là qui est client et qui est serveur...
Bref je titille mais je pense qu'ensuite c'est plus facile à
présenter.

> /!\ Question, les initialiseurs de struct de ce type sont compatibles avec 
> tous les
> compilateurs que l'on utilise?

Je ne sais pas mais de toute façon je ne suis pas pour des inits
statiques de ce genre et ceci pour 2 raisons:

  - elles peuvent être faites dans TSP_consumer_init().
    qui viendra "enregistrer" le/s canal/aux de commande côté
    consumer comme TSP_provider_rqh_manager_init()
    est appelé dans TSP_provider_init.
    D'ailleurs plus exactement c'est ensuite au moment
    du  TSP_provider_run qu'on TSP_provider_rqh_manager_install
    pour installer le/s handlers de commande qui sont dispos.
    (je ne me souviens plus pourquoi on fait
     ça au moment du provider_run d'ailleurs mais bon c'est
     peut-être une erreur)

  - on peut imaginer sans trop de peine pouvoir coder/fournir
    des canaux de commandes sous la forme de librairies dynamiques
    qui sont chargées automatiquement par le  TSP_provider_init
    côté provider et TSP_consumer_init côté consumer.

D'ailleurs j'avais plutôt pensé le multi-canal A CAUSE de ça.
Je veux utiliser TSP dans un contexte réseau particulier qui
tolère pas le rpc,xmlrpc etc...
Il me suffit de coder le provider_request_handler côté provider et 
le consumer_request_handler, je droppe mes 2 libs partagées
là ou ça va bien et hop

je redémarre mon bb_provider qui parle via le nouveau canal
et je redémarre gdisp+ qui parle aussi via le nouveau canal.

ce serait sympathique non?

> 
> - d'ajouter un tableau global du genre
> TSP_client_operations available_transports[] = {
> 
> #ifdef RPC_TRANSPORT
>       rpc_client_ops, 
> #endif
> 
> #ifdef XMLRPC_TRANSPORT
>       xmlrpc_client_ops,      
> #endif
>       NULL
> }

Même remarque un tableau statique dimensionné à une taille max (5 ou 6)
plus un fonction pour venir enregistrer le/s canal/aux de commande 
dispo dans ce tableau.

> Ce tableau serait parcouru par le TSP_connect_url qui trouverait le bon
> transport en appelant xxx_client_ops.TSP_protocol() et en le comparant
> au protocole de l'URL

Ca c'est une bonne idée.

> 
> Voilà, je suis preneur de toute idée/suggestion/bière :)

Merci de ton analyse très claire du problème il n'empêche que
...J'offre la bière très bientôt :))

A+
Eric
> 
> A+
> Fred
> 
> [1] Le basque étant en passe de rejoindre le français comme langue de
> communication des développeurs TSP, je me mets au goût du jour
> 
> 
> _______________________________________________
> Tsp-devel mailing list
> address@hidden
> http://lists.nongnu.org/mailman/listinfo/tsp-devel
>