For the most part I don't. The only section that is not settable in the app is exclude files. So human readability will no longer be that important.
On Fri, Jul 12, 2019, 6:11 PM Rich Pieri <[email protected]> wrote: > On Fri, 12 Jul 2019 16:16:15 -0500 > Derek Martin <[email protected]> wrote: > > > I largely disagree. If it's currently in INI format the equivalent > > JSON should generally be perfectly human-readable, e.g.: > > Computer-generated JSON can be human-readable. Doesn't mean it will be. > Often enough it is not. Very not. For example, my Calibre metadata > sources cache is 174KB dumped into 24 lines of text one of which is the > open brace and another is the close brace. That's 22 lines of > unreadable, computer-generated JSON. Admittedly that cache isn't > easily stored in simple key/value pairs because it's not simple > key/value data like your example. Use JSON if you need to store complex > data. Otherwise I suggest avoiding it. > > Avoid YAML. It's great for Ansible because Ansible has test modes so > you can verify that the code acutally does what it's supposed to do > before it wrecks things. Unless you're exposing your configuration > parser for external testing then YAML should be taken off the table. > > INI and TOML are basic key/value stores. They are easily read and > modified by humans and there are parsers available in pretty much any > language you care to use (they're also not difficult to write if you > have an exception). If you need human readability (and optionally human > writability) then either INI or TOML are good choices to consider. > > -- > Rich Pieri > _______________________________________________ > Discuss mailing list > [email protected] > http://lists.blu.org/mailman/listinfo/discuss > _______________________________________________ Discuss mailing list [email protected] http://lists.blu.org/mailman/listinfo/discuss
