[Conseils] Quelle norme de-facto pour format INI ?

**JPDMJC** · 31/12/2007, 15h57

Bonjour,
je développe depuis un bout de temps une bibliothèque de gestion de fichiers de configuration :INI, XML, Properties, etc etc ...
Il existe des normes pour bon nombre de formats, mais apparemment aucune officielle pour le format INI, juste des usages.
Je me suis pour l'instant basé sur la bibliothèque ini4j, ainsi que sur la description de Wikipedia et une norme non officielle.

Seulement je m'interroge sur un exemple tiré des fichiers de tests fournis avec ini4j : l'include.
Apparement il serait possible de faire appel à d'autres fichiers via la syntaxe :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

< monFichierAIclure.ini >

et cela n'importe où dans le fichier ini.

Ma question : A votre avis, cela vaut-il le coup de l'implémenter ?
J'essaie de faire une bibliothèque facile à utiliser, et surtout très performante (et pour l'instant ça marche à merveille).
Ne voyant cette syntaxe que dans l'exemple fournit avec ini4j, j'hésite à alourdir (même très légèrement) mon bousin.

D'avance, merci

PS : désolé si le sujet n'est pas dans la bonne catégorie, mais là je sèche ^^.

**JPDMJC** · 23/01/2008, 14h28

je me permets juste un petit "up", des fois que.
Désolé pour le dérangement.

**gorgonite** · 23/01/2008, 14h32

je pense qu'un simple préprocesseur avant de passer le fichier à un parseur ini standard pourrait suffire...

Invité · 23/01/2008, 23h16

Hello Jpdmjc,

Quelles sont tes craintes en termes de performances? Etant donné que tu manipules quelques kilo-octets de fichiers texte, qui a priori ne sont lus et parsés qu'au démarrage et peut-être à quelques rares occasions suivantes, il me semble que tu peux t'affranchir complètement de ce type de craintes pour te concentrer (comme tu le fais déjà!) sur des fonctionnalités plus intéressantes comme la conformité à des standards répandus par exemple.

Si tes utilisateurs ont besoin d'includes et que cela ne gène pas ceux qui n'en ont pas besoin, je ne vois pas de raison de ne pas l'implémenter.

Cheers,

Carl