.ini or XML as config file

[akshay2008]

Hii all,

I want to implement a configuration file for my  Testsystem.

what is recommended  ?  what  is more advantageous considering the Testsystem will run for next 10 yrs and  considering the fact that the Config file should be flexible, portable and   extensible.

the same old .ini file  or an XML file.

regards,

Akshay

[Norbert_B]

Akshay,

you have to find the answer yourself.

Using LV to implement the system, you can use Configuration File VIs (INI files) or XML parsing functions to get/write information from/to the document.

What are you looking for exactly? What type of configuration data do you intent to keep in the document?

Norbert

[P@Anand]

Both these file formats are portable. Generally for complex systems and if it is for productions test we generally prefer XML which will include complex configuration parameters. 

For an instance if you have a configuration in a cluster you can easily convert that into XML and store/retrive which you cannot do it with INI files.

So my opinion would be to go for an XML file if you involve lot of parameters.

[Sam_Sharp]

My preferences are either:

- An INI file: human readable, not strictly typed (e.g. if you use the MGI/OpenG INI file functions, it will still work if you change the structure)

- JSON: as above, but allows for a slightly neater hierarchy

- A database (either as an sqlite file or connecting to a database engine): Allows you to keep a 'history' of

I'm not a fan of XML because it pads the file sizes quite a lot and unless you read out the items individually, LabVIEW has problems using 'unflatten from XML' if the type changes (all values will be default, instead of just missing items). The standard LabVIEW XML schema is unnecessarily complicated.

[akshay2008]

thnks Norbert & Anand,

thts wht I was looking for.

I may integrate clusters thr' Config file therefore XML  is a strong contender.

[MarcDub]

As an additional option, you can use a class saved as an XML file. This way, LabVIEW would manage for you backward compatibility of your config files. Meaning that if your configuration file changes in the future, your new application would still be able to read the old config files. LabVIEW classes are saved with change history, making this possible.

Have a look at the following posts (among others):

https://decibel.ni.com/content/docs/DOC-31272

https://decibel.ni.com/content/docs/DOC-26776

[mikeporter]

My recommendation would be a database. They are easy to use, free, structured and have security benefits.

Mike...

[drjdpowell]

---

@akshay2008 wrote:

I may integrate clusters thr' Config file therefore XML  is a strong contender.

---

Don't use XML.  There are free tools to easily handle clusters with INI (OpenG/MGI) or JSON.  XML is both too complicated and too strict about cluster type (as Sam_Sharp pointed out).  

[Bob_Schor]

It is a good thing I didn't read Dr. Powell's recommendation 5-6 years ago when searching for a more flexible way of handling Configuration Files that would be more "friendly" with LabVIEW structures such as Arrays of Clusters.  I ended up settling on XML (I use NI GXML, from the NI Tools Network) which works very well for me.  I especially like the fact that I can open a Config file with NotePad and quickly see what's what.  I also use this to write some of my data files that are "episodic" in nature, for example, the Experiment Header File, consisting of several sections, including the Configuration data used for the Experiment and a Trial-by-Trial list of the parameters employed with each trial.  I should say that I'm taking advantage of the ability to write XML data "a piece at a time" rather than "all-at-once" -- for example, I write a Trial cluster at the end of each Trial, as opposed to writing an Array of Trial Clusters (also a valid XML entity, but I don't know what the entire Array will be until after they are all run, and I want to save data "on the fly" ...).

Bob Schor

P.S. -- I'm hoping to have some "spare time" to allow me to develop a variant of GXML that will circumvent XML's "naming" rules that forbid certain characters in XML Tags, elements that are legal LabVIEW names, making for some ambiguity in creating XML that rigorously maps LabVIEW variables.  I have an idea ...

[drjdpowell]

Ah, I hadn't seen GXML before.   That does look far more user-friendly that the regular XML parsing API.  Playing around with it, though, it seems to retain an excessive strict typing that I wouldn't want in a config file.  It's even more strict than LabVIEW, as one can't even extract a "DBL" as "SGL" or "EXT"! 

Here's a comparison, taken from one of the GXML examples, of XML with the equivalent JSON.  Note the minimal type specification in JSON.

<GXML_Root>

  <Test_Info mems='2'>

    <Enable type='Bool'>TRUE</Enable>

    <Test_Name type='String'>Collection 1</Test_Name>

  </Test_Info>

  <Log_Info mems='2'>

    <Destination type='Path'>C:\TestData</Destination>

    <File_Name type='String'>Test_0530</File_Name>

  </Log_Info>

  <Scale_Info mems='2'>

    <Offset type='DBL'>0.5</Offset>

    <Sensitivity type='DBL'>50.1</Sensitivity>

  </Scale_Info>

</GXML_Root>

{

  "Log Info": {

    "Destination": "C:\\TestData",

    "File Name": "Test_0530"

  },

  "Scale Info": {

    "Offset": 0.5,

    "Sensitivity": 50.1

  },

  "Test Info": {

    "Enable": true,

    "Test Name": "Collection 1"

  }

}