Re: [Tsp-devel] TSP post-0.8.0: appel à contr ibution.

[Stephane GALLES]

Erk wrote:
> 
> Merci de me dire si l'un ou l'une d'entre-vous souhaite prendre en charge
> une des grandes lignes qui suit. 
[...]
> B) Utiliser libtspcfg.
>    La libtspcfg a fait son apparition et permet de charger/sauver
>    un fichier de config XML. J'aimerais que tous les consumers
>    puisse utiliser ce format. Aujourd'hui seul l'ascii_writer peut le
> faire.
>    C'est redondant avec le format de fichier XML de targa mais
>    j'espère qu'on pourra discuter les avantages/inconvénients des 2
>    formats pour converger vers un format unique.
- En JAVA : j'avais fait il y a environ un an une implémentation de ta
toute 1er spec de conf XML. Est ce qu'on veut une réimplémentation avec
ce nouveau format ? Si oui, est ce qu'on veut que cette conf soit
maintenant exploitable avec l'API JTSP old school ? (car je pense que la
1er implémentation de la conf XML en JAVA vivait plutôt dans le monde de
l'API JTSP 'Simple', qui, on a dit, n'a maintenant plus qu'un intéret
académique).
- En Ruby : Est ce qu'on veut une implémentation de cette conf XML ?
(cela m'intéresse car je n'ai pas encore trouvé de raison valable de
jouer avec le très élégant parseur REXML livré avec Ruby ! ). Est ce
prématuré / overkill ?
[...]
> 
> D) XML-RPC
>    La version actuelle fonctionne mais elle n'est pas compilée par défaut.
>    Ce serait réellement utile que quelqu'un prenne ça en charge afin
>    que l'XML-RPC soit compilé par defaut (côté provider)
Cela pourrait m'intéresser mais mon manque de connaissance de CMake va
sans doute me ralentir, et puis il faut que je me replonge dans le code
C. Si cela n'intéresse personne d'autre je veux bien regarder, mais cela
risque de prendre un certain temps (en particulier si tu veux le faire
Fred, n'hésite pas, car tu iras sans doute ->beaucoup<- plus vite que moi !)

Une question au passage : est ce la partie XML-RPC à été mise à jour
pour envoyer les infos multi-types / tableaux ? est ce que cela reste à
faire ?
> 
>    Une fois que c'est fait on pourra:
>       D.1) mettre à jour rubytsp
Je suis volontaire, bien sur ! (Hey ! merci Eric pour l'info sur le
numéro du LinuxJournal consacré à Ruby, les articles sont excellents !)

[...]

> H) Gestion des releases TSP
> 
>     Pour l'instant je "gère" la sortie des versions pour le C et Java
>     et les autres modules "vivent" leur vie sans gestion "réelle"
>     des versions.
> 
>     H.1) TSP en C
>     H.2) jTSP
>     H.3) pytsp
>     H.4) perltsp
>     H.5) rubytsp
j'imagine qu'il faut que les modules aient toujours le numéro de la
version C avec laquelle ils sont chacun compatibles ? Je peux faire cela
pour Ruby si tu veux (dès qu'il y a une version C avec laquelle le
module Ruby fonctionne 'out of the box' ce qui ne doit pas être le cas
actuellement)

> 
> J) Prendre en charge la conception de ts2p.org
> 
>    J'ai ouvert et enregistré www.ts2p.org, histoire de garder le nom de
> domaine
>    car www.tsp.org est déjà pris :(((.
>    J'ai fait un premier jet de pages html minables. (www.ts2p.org/tsp)
>     Fred D. en a fait un deuxième (www.ts2p.org)
>    Aujourd'hui c'est en chantier mais ce serait cool
>    d'avoir un site "opérationnel" même minimal.
>    Je fournirais volontiers les accès au(x) volontaire(s).
> 
Je ne veux pas lancer trop de sujets en même temps, mais est ce que la
réflexion sur l'utilisation éventuelle de forrest
(http://forrest.apache.org/) avait avancé ? ou bien tu n'en parlais pas
parceque cela avait été abandonné ?

A+

Steph