Re: [Tsp-devel] Etat du canal commande XMLRPC ?

[Erk]

Le 23/03/06, Stephane Galles<address@hidden> a écrit :
>
> (note : ce message semble s'être perdu, je le reposte, j'espère qu'il ne
> sera pas reçu en double)

Comme je le notais précédemment y'a des soucis sur lists.gnu.org
http://savannah.gnu.org/forum/forum.php?forum_id=4322

>
>
> Je voulais activer le sympatique canal de commande XMLRPC de Frède pour
> essayer une petite chose que j'avais derrière la tête, et je n'ai pas réussi
> à le compiler.
>
> J'ai l'impression que le code du canal XMLRPC n'a pas suivi les évolutions du
> reste de TSP.

C'est vrai et je suis en parti fautif vu que je n'ai pas pris/eu le temps
de faire évoluer cette partie de code en même temps que le reste.

En plus après discussion privé avec Fred je serais assez pour réactiver
systématiquement la partie provider, mais pas la partie
consumer car l'API consumer n'est pas [aujourd'hui] conçue
pour supporter simultanément +ieurs canaux de commande.

Côté provider c'est OK avec le "request handler manager".
Je pense d'ailleurs, mais c'est bien évidemment discutable,
que le XML-RPC côté consumer n'est pas forcément très utile.

Je m'attends plus à ce que ce soit des consumers 100% scripts
(perl, python, etc...) qui utilisent ce canal dans ce cas
autant faire du XML-RPC 100% python/perl/ruby...
et pas de C+ SWIG + script.

Cela permettrait aussi d'avoir des clients scripts "portable".

Pour un consumer en Java même combat autant faire du 100% java.

>
> On dirait en particulier que la présence des fonctions async lui pose
> problème à la compil. Il y a aussi une modification de la fonction
> GLU_get_server_name (en GLU_get_server_name_ft ? ) qui coince je crois.
>

Pour les async c'est sûr on/je/fred n'a pas fait évolué le code
depuis ces rajouts.

> Un problème aditionnel semble venir du fait que sur une toute nouvelle
> arbo co de cvs, le fichier tsp_rpc.h n'est pas généré si on active une
> compile xmlrpc directement. Donc il semble qu'il faut lancer une compile
> traditionnelle pour générer le tsp_rpc.h, puis, lancer la compil xmlrpc,
> qui, étrangement, semble quand nécessiter la présence de tsp_rpc.h

Oui c'est un vieux pb qu'on traine, du au fait que nos structur 'C'
TSP sont DIRECTEMENT celles générées par rpcgen.

Idéalement les structures "publiques" de TSP devraient être déclarée
dans src/core/common
et les API, core/consumer/provider utiliser ces structures.
Les structures "spécifiques" du canal de commande
 devraient être construites à partir de ces structures TSP.

Pour l'instant on avait 1 canal de commande RPC et des structures
directement issues de ça....

On a déjà un peu discuté d'une solution du genre IDL qui nous permettrait
de générer les stubs pour différents canaux de commande.

>
> Etant donné que je manque de connaissance concernant ces évolutions du code,
> pouvez vous me dire si vous constatez le même problème quand vous compilez
> sur vos machines ? Ou bien est ce moi qui fait quelque chose de bizarre
> avec mes mains pleines de doigts sur mon clavier ?

Ben non j'ai pas de problème.... tant que je le compile pas :))
Donc c'est pas bien mais pour l'instant ce n'est pas maintenu par manque
de temps (en tout cas en ce qui me concerne).

Qu'est-ce que tu veux faire avec?

>
> Une autre question, XMLRPC en est maintenant à la version 1.3.2, est ce que
> TSP a suivi cette évolution, ou bien faut - il utiliser la 1.2 ?
> (effectivement, la version 1.2 est super pénible à compiler)
>

Je ne sais pas je laisse Fred répondre.

--
Erk