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

[Stephane Galles]

Merci pour vos réponses Fred et Eric !

Mais je ne voulais pas provoquer un mini cataclysm dans votre plan de 
marche !

Si la remise en marche de ce canal XMLRPC n'était pas prévu à court terme,
ne le faite pas uniquement parceque j'ai évoqué l'idée que je voulais 
jouer avec ; cela va
sans dire.

Ce préalable étant posé, voici ce que j'avais en tête :

Effectivement, je m'intéresse à la partie serveur du canal. Et effectivement
ce serait pour faire un provider en language script pur, sans wrapping.

Par contre le language ne serait ni du Perl, ni du Python...
...mais du Ruby. Je me doute que cela n'aurait pas vraiment été votre 
1er choix,
vu que j'ai cru comprendre que des choses existent déjà en Python pour TSP

Mais la raison pour laquelle je veux faire cela en Ruby est que je suis 
en train d'apprendre
ce sympatique language, et que la création d'un client TSP en Ruby pur 
me paraît un excellent
exercice, tout en ayant la possibilite de produire quelque chose de 
potentiellement utile.
Et puis Ruby 1.8+ arrive en natif avec une librairie XMLRPC.

Mais maintenant vous comprenez aussi pourquoi je ne veux pas que vous 
bousculier
vos plans : le choix de ruby est purement personnel (sans lancer ici un 
débat
pour/contre perl/python/ruby, je dirai simplement que ruby me convient 
mieux comme
language de script car il est plus objet que python ou a fortiori perl 
(voire même java ou c++);
ex : en ruby le chiffre 3 est un objet et je peux  imprimmer trois 
fois"tsp rules"
en écrivant :          3.times { puts 'tsp rules' }          Ca c'est 
objet !  )

D'autre part, je ne sais pas du tout à quelle vitesse je compte faire 
cela. Mais au moins j'imagine
qu'avec Ruby je ne suis pas sur un crénau trop occupé et que je ne vais 
géner personne
en avançant doucement (hum...c'est vrai ça au moins ? personne n'était 
parti pour utiliser
Ruby avec TSP, hein ?! )

Sinon, je trouve effectivement que c'est une excellente idée que le 
canal XMLRPC soit
tout le temps compilé dans le serveur, mais que la partie cliente ne 
soit pas compilée
(de toute façon comme vous disiez, ce canal client n'est pas vraiment 
utile en C qui a un accès
facile au canal RPC)

Voila, voila...heu... désolé pour le dérangement, je ne faisais que 
passer...

PS : Pour la présence des structures RPC dans tout le code TSP, mea 
culpa. C'est moi
qui ai fait sortir la bête de sa tanière lors du prototypage de TSP, et 
après avoir
gouté à la lumière du jour, elle n'a jamais voulu disparaître.


Frederik Deweerdt wrote:

> On 3/23/06, Erk <address@hidden> wrote:
>  
>
> > Le 23/03/06, Frederik Deweerdt<address@hidden> a écrit :
> >    
> >
> > > On 3/23/06, Stephane Galles <address@hidden> wrote:
> > >      
> > >
> > > > J'ai l'impression que le code du canal XMLRPC n'a pas suivi les évolutions du
> > > > reste de TSP.
> > > >        
> > > C'est le moins qu'on puisse dire, j'ai essayé une compilation il y a
> > > peu, et ça plantait. J'avais remis ça a plus tard, mais si tu comptes
> > > l'utiliser, je vais essayer de remettre ça d'aplomb rapidement.
> > >      
> > Je suis bien sûr pour :))
> > Toutefois pour épargner du travail inutile à Fred,
> >    
> Je suis pour ça aussi :)
>  
>
> > Je dis ça également car Arnaud et moi-même nous apprêtons à
> > patcher copieusement le tsp_rpc.x pour
> >      - ajouter la gestion du multi-type
> >      - corriger l'erreur de design des async_read et write
> >      - ajouter la gestion des attributs étendus.
> >
> > Je devrais pouvoir fournir un .x quasi à jour Mardi ou Mercredi
> > de la semaine prochaine, les implém' provider et consumer
> > ne seront peut-être pas toutes fonctionnelles toutefois l'API
> > sera là.
> >
> > Dîtes-moi ce que vous préférez tous les 2.
> >
> >    
> OK pour un xmlrpc uniquement côté provider: les consumers potentiels
> seront des scripts avec xmlrpc en natif, ça semble raisonable.
>
>  
>
> > > > 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)
> > > >        
> > > C'était bien une lib =<1.2, et xmlrpc a pas mal évolué depuis. Je vais
> > > rejetter un coup d'oeil et je te tiens au courant de l'ampleur des
> > > dégâts :)
> > >      
> > Vous pourriez rappeler de quelle lib vous parlez? avec l'URL
> > parce qu'il me semblait que c'était celle-là
> > http://xmlrpc-c.sourceforge.net/
> > que Fred avait utilisée
> > et la dernière version me semble être xmlrpc-c-1.03.12 ?
> >    
> C'est bien celle-là, il semble qu'à partir de la 1.2, il ait renuméroté ses
> releases en 1.02, 1.03 etc..
>  
>
> > D'ailleurs un petit README dans src/core/xmlrpc ne ferait pas
> > de mal voire mettre les infos directement dans la doc doxygen
> > de src/core/xmlrpc/tsp_xmlrpc_server.h.
> >    
> OK, je documenterai ça après avoir pu compiler tsp-xmlrpc avec une lib
> xmlrpc récente.
> A+
> Fred
>
>
> _______________________________________________
> Tsp-devel mailing list
> address@hidden
> http://lists.nongnu.org/mailman/listinfo/tsp-devel
>
>
>