[Tsp-devel] libtspcfg

[Erk]

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

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 :))
[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...

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

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

1) comment gerer "proprement" les parties consumer-specfiques
   "Layout", balise <TSP_samples_layout>

   Dans l'exemple de fichier en conf ci-dessus il n'y a pas de partie
   specifique. Mais Targa, GDisp, et d'autres ont besoin de ces
   layouts specifiques pour "presenter" les samples decrits
   dans la partie "generique".

   Pour gdisp/targa c'est mettre en page/viez/draw
   Pour l'ascii_writer c'est ordonner les colonnes etc..
   Pour d'autres ce sera reconstruire une trame...

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

     <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.
             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 ne sais pas si je suis tres clair?

--
Erk