New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

INI file format vs. others (JSON, YAML, XML...) #914

Open
borekb opened this Issue Apr 12, 2016 · 6 comments

Comments

4 participants
@borekb
Member

borekb commented Apr 12, 2016

From time to time, we consider whether we should continue using INI as our DB-mirroring file format. I'm creating this issue to document the issues, possible alternatives and our thinking in general.

Design goals

The goal of our format is to be as friendly as possible to diffing and merging. This drives everything. The power users will work with the format in diff tools and even in our current UI, users can go to the Details panel (#49) and with the full diff.

The format needs to be simple and preferably without indentation. This all lead to the decision to use an INI format as soon as issue #1.

What we don't like about INI

First and foremost, parse_ini_string() is buggy in many edge cases (and we exercise the format quite to the limit), or perhaps it's more fair to say that it was created to parse php.ini only and supporting the whole INI spec was an afterthought. We have many workarounds already in our IniSerializer class and are still encountering new issues like #910. We're even considering writing our own parser: #912.

Then, a smaller thing, INI format just isn't "cool" in a sense that we have this old, archaic thing in an otherwise greatly progressive project. But that's obviously just a very minor thing.

Alternatives

  • YAML: has significant whitespace. We don't want that.
  • JSON: the whitespace is at least not significant. JSON is quite a popular format in these JavaScript days but the diffs would be a bit harder to read because of the indentation (wasted space) and if the content was multi-line (like longer blog posts), it would look a bit weird – the first line starting at some column like 20, the other paragraphs starting at column 0.
  • XML: you've got to be kidding right? :)

@JanVoracek JanVoracek added this to the 4.0 milestone Apr 24, 2016

@drupalista-br

This comment has been minimized.

drupalista-br commented Sep 23, 2016

In regards to the parse_ini_string(), you can replace that with zendframework/zend-config. Docs at https://github.com/zendframework/zend-config/tree/master/doc/book

Although zend-config ini uses parse_ini_string() function, the zend team did all the heavy lifting.

@borekb

This comment has been minimized.

Member

borekb commented Sep 24, 2016

@drupalista-br Could you point to unit tests covering all the tricky INI scenarios, similar to our IniSerializerTest? Unless there's such test suite I don't trust the parser :)

@borekb

This comment has been minimized.

Member

borekb commented Sep 28, 2016

Just a thought but maybe we could use a .vp file extension; I dislike mentioning INI in the documentation :)

@borekb borekb added this to New in 4.0 beta -> final May 9, 2017

@ustun

This comment has been minimized.

ustun commented Sep 12, 2017

@borekb

This comment has been minimized.

Member

borekb commented Sep 14, 2017

@ustun TOML seems nice, thanks for the pointer. In practice, it's a bit problematic adopting any niche language and we already switched once (NEON -> YAML, #703), but it's always nice to have options.

@borekb

This comment has been minimized.

Member

borekb commented Aug 17, 2018

Just going to say here that I encountered TOML in some React-related projects, read up a little bit on it (e.g., this discussion on whether to make it fully compatible with INI) and I like it.

This is a nice statement, IMO: toml-lang/toml#411 (comment).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment