Re: [Tsp-devel] libtspcfg

[Stephane GALLES]

Erk wrote:
>>> 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
>> oute 1er spec de conf XML. Est ce qu'on veut une réimplémentation avec
>> ce nouveau format ?
> 
> La libtspcfg s'appuie sur la 1ere specs + des ajouts.
> Nous (Julien BRUTUS) a mis a jour ton implem' initiale en Java
> pour tenir compte de ces ajouts/modifs.
Ha ! J'avais pas vu, désolé ! Je savais que Julien avait ajouté la
gestion des multi-types/tableaux, mais je ne savais pas que la conf
avait suivi ! Cool.
> 
> La libtspcfg en C a ete implementee par Arnaud MORVAN
> son but est de founir une API 'stable' liee aux structures du code TSP
> qui encapsule les "cochonneries XML" des appli. consumers qui
> l'utiliseront.
> 
>> 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
> 
> cf ci-dessus.
> Ton implem' initiale me va bien meme si elle manque un peu de doc :))
(oui, effectivement...c'est promis dès qu'on a un wiki JTSP je fait
un petit laius la dessus)

> [comme pas mal d'autres parties de TSP en C ou Java d'ailleurs...]
> 
>> 'API JTSP 'Simple', qui, on a dit, n'a maintenant plus qu'un intéret
>> académique).
> 
> Le parsage de conf XML est clairement d'interet general et pas
> seulement pour JTSP SImple.
> 
> Pour JTSP Simple me parait "moins utilie" mais c'est a voir a l'usage...
No problemo. On pourra le sortir si on voit que cela ne sert plus à rien.

> 
>> - 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 ?
> 
> Bien sur l'ideal serait que tous les consumers soient capables de
> lire/ecrire le meme format de fichier.
Plus tard je ferai donc une implémentation pour Ruby de la conf XML
(mais il y a d'autres choses qui passent avant. En particulier la
compilation du XML-RPC dans la partie C me semble plus importante)

> 
> Il reste 3 choses majeures a resoudre avec ce format de fichier:
> 
> 0) ecrire la DTD voire le schema XML qui correspond, histoire
>    de pouvoir faire des parseurs qui valident.
> 
> http://cvs.savannah.nongnu.org/viewcvs/tsp/src/util/libtspcfg/tspcfg_example.xml?rev=1.1&root=tsp&view=markup
Je peux me charger d'écrire un schéma si tu veux; par contre l'exemple
de cette URL ne semble pas contenir d'autres types que double et pas de
types tableaux. Est ce que tu aurais un autre exemple plus varié ? Cela
m'éviterait d'avoir à trop repartir du code libtspcfg ou bien JAVA pour
créer le schema. Vous avez du utiliser des fichiers plus complexes lors
de vos tests ?

> 
> 
> 1) comment gerer "proprement" les parties consumer-specfiques
>    "Layout", balise <TSP_samples_layout>
Il faudrait valider cela, mais j'ai l'impression que c'est typiquement
le genre de problèmes résolus par les espace de nom XML.
http://www.rpbourret.com/xml/NamespacesFAQ.htm#q8_5
 [...]
> 
>    L'idee est que toutes les balises qui sont contenues
>    dans:
>    <TSP_samples_layout>
> 
>    </TSP_samples_layout>
> 
>   sont specifiques et peuvent "referencer" les samples definis
>   dans la partie generiques.
> 
>   on peut imaginer une balise
>       <targa_layout>
Si mon hypothèse sur les espaces de nom tiennent cela pourrait être
        <targa:layout>
>         .....
>      </targa_layout>
> 
>      <tabular_layout>
et      <tabular:layout>
>         ....
>      </tabular_layout>
> 
>    Toutefois les libs qui permettent de parser ces fichiers sont concues
>    de facon telle que:
>              a) les <xxx_layout> inconnus de la libs peuvent etre
> ignorees silencieusement.
Autrement dit, ce sont les espaces de noms qui sont connus/inconnus
>              b) la lib peut etre "facilement" augmente par un
> consumer specifique
>                  qui voudrait rajouter son layout specifique.
> 
>    Ceci permettrait d'echanger facilement des fichiers de conf entre
> consumer
>    differents (eventuellement dans differents langages) en augmentant
>    evnetuellement le fichier original de la partie layout specifique.
> 
> 2) Que chaque consumer se definisse ses layouts specifiques
Je n'ai jamais utilisé cela à fond, mais je pense qu'avec les espaces de
nom chaque consumer peut avoir son schéma spécifique.
> 
> Je ne sais pas si je suis tres clair?
> 
Cela me semble clair.
Si cette histoire d'espace de nom te semble intéressante je peux creuser
cela, et en particulier voir l'interaction de cela avec le schéma du fichier

Steph