Now that I have being looking into configurations in application bit and also looking at it from the point of the developer a question has come up. What file format should a configuration file be in. There is a couple of question we can ask to get a bit more of an understanding of the requirements need and we will cover that in this post. I should point out there are too many formats to cover in detail. If I miss a format that would be perfect please get in contact I would love to know.
Lets look at some of the questions so we can work out the requirements of our file format.
The first question, is there a parser for this file format in my language of choice? For almost all formats this will be yes but it does mean creating your own format is not the idea.
What is the native support for the file format on the platform the application is targeting and being developed on? If the user is expected to interact with the configuration file this matters. They may or may not get syntax highlighting.
Is the format human readable? Even if you never expect the end user to interact with the configuration file, if your application is popular, some power users will edit that file.
Is the specification for the format well defined? While this is a bit more of as a development team we are going all in on this standard. If the format is well define any language used by the development team should parse the configuration files the same. This improves the chance developers will want to use the format.
Can you add comments to the configuration file? This is super important even if the end user is not meant to edit the files. The developers will and when there is a new setting added it would be nice to explain what it does to them.
With these five questions we can look at few formats.
Json is the standard format used in the internet. That does mean for any language you think of, there is going to be a parser for it. Native support is a bit different, for me on Linux the more developer friendly platform json files open in my browser by default. To me that looks like native support is poor. For being human readable, oh json is not. Most humans are not developers so then need for curly brackets will not be understood. For the specification being while defined, while the link I give goes to wikipedia. For the most part there is nothing wrong with wikipedia but this a standard why did I not link to that. The reason I did not link to any of the specification pages for json was they were using http and not https. And the last question was can you add comments to it. No, no you can not. When looking at json it almost seems that the format was designed to be machine readable and that's why half the internet runs on it.
Yaml is the next standard that I want to talk about. There are many parsers for yaml and the standard is widely used. If you have done any work with kubernetes you have worked with yaml before. Platform support is better in I never need to change any system setting to get the format to open in correct editors with syntax highlighting. Is the format human readable yes I think it is. There is can be some confusion when working with deeply nested list items but over all it is a good format. The specification is well defined but it is large. There is a lot that yaml specification allows to be done, such as creating variables within the file to be used in other parts of the file. While this is a good feature to have it is possible not the correct feature you want in a configuration that can be used by an application. Yaml does allow the creation of comments in the files so that is a plus.
Next format is the ini file format. While looking into this I could not find the specification for the standard and this seems to a problem when you look at the features the different parsers have for the format. So while there is many parsers out there you will have to check the support features. Is the format human readable. Yes, this is one of the reason the format was created. This means the format supports adding comments which is good. Native support does seem to be good. This format would be a good choice for application settings.
The last format that I am going to talk about is toml. This is also a format that was designed to be human readable. From my research there seems to be parsers in most languages, all the language I work with has a parser. Native support seems to be there, which is good. The specification is well defined and does not take long to read. There is no fancy bells and whistles like what yaml has. As the format was design to be human readable it also allows for comments. The structure is very like that of ini file but the specification does define how dates should be formatted for example.
While all these formats have their pros and cons, for the use case of application configuration editable/readable by the user I think toml is the better choice. The format was designed to be a simple configuration format. So that is my take on this. I have being looking in configurations and have a few related posts. You can find the other posts here.
