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

[julien.brutus]

Good morning troops,

J'ai remonté sous CVS le tarball pytsp.tar.bz2 dans pytsp.
Je l'ai validé avec TSP 0.7.3.
A+

-----Message d'origine-----
De : address@hidden [mailto:address@hidden De la part de Erk
Envoyé : vendredi 24 mars 2006 07:21
À : Transport Sample Protocol development list
Objet : Re: [Tsp-devel] Etat du canal commande XMLRPC ?

Je fais 2/3 réponses courtes.
J'en ferais peut-être une autre plus longue
hitsoire de troller un peu sur Ruby :))

Le 24/03/06, Stephane Galles<address@hidden> a écrit :
>
> Merci pour vos réponses Fred et Eric !
>
> Mais je ne voulais pas provoquer un mini cataclysm dans votre plan de
> marche !

Pas de pb TSP est guidé par ses utilisateurs, y compris
ceux qui veulent "jouer" pour faire des choses intéressantes.
C'est source de bonnes idées.
>
> Effectivement, je m'intéresse à la partie serveur du canal. Et effectivement
> ce serait pour faire un provider en language script pur, sans wrapping.

Cool :)))

>
> 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

Pour l'instant c'est avec SWIG, je réfèrerais à terme
100% python mais tant qu'il n'y avait que le canal ONC-RPC de 100%
fonctionnel c'était plus "faisable" avec SWIG.
C'est Julien BRUTUS qui a fait le wrapper Python,
ce n'est pas encore dans CVS (mais le tarball a été envoyé sur la liste)

http://lists.nongnu.org/archive/html/tsp-devel/2006-02/msg00012.html

Pour les langages de scripts on a crée des modules CVS de haut niveau

pytsp/tcltsp etc...

si tu veux un rubytsp c'est sans pb.


>
> 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.

Je suis d'accord très bon exercice puisqu'il pourrait nous profiter :))

> 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 !  )

=====+++> troll détecté
ne pas répondre de suite :))

>  personne n'était parti pour utiliser
> Ruby avec TSP, hein ?! )

Non tu as raison.

>
> 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)

Ok.

>
> 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.

C'est le classique du prototype qui marche bien et qui est utilisé
pendant plus de 3 ans :))
C'est logique et c'était un bon choix de l'époque.

C'est le moment de changer un peu ça on va le faire tranquillement.

--
Erk


_______________________________________________
Tsp-devel mailing list
address@hidden
http://lists.nongnu.org/mailman/listinfo/tsp-devel