Ask HN: What do you like to see in a configution file format?

a big plus one for both these items mentioned. and annoyance I've encountered with some configuration files is the lack of a built-in comment line so I can communicate in line with the configuration decisions to a future user.

Your comment about variables for usable values reminded me that it would be nice if the configuration file parser could reference other variables and sections of the configuration file to avoid repeating oneself in the same configuration file. for example, if the configuration files describing a fleet of virtual machines, it would be very handy to define small/medium/large system types with varying RAM, CPU counts, and disk layouts, then reference just the small, medium, or large type throughout the configuration file.

Thank you. I agree, I think yaml is the right choice for this application. Thanks for your thoughts in both comments you posted.

Thanks, these are great tips.

>concise: json, yaml and xml are too verbose imho I'm very surprised you include yaml in this. It doesn't seem to require me to use any syntax except a colon to separate the name from the value. (and optionally indentation to specify when something is logically a child value). How can that be too verbose? What would be a less verbose version?

You and others have all mentioned variables and placeholders to avoid repetition. How do you suggest specifying a variable?

> unambiguous: indentation, capitalisation, the type of quotes etc shouldn't be syntactically relevant

since you say types of quotes shouldn't be relevant how do you suggest I differentiate a generated image from a named one? I was thinking of making it:

module_image:"images/module.png"

to specify the path if the user created their own image, or allow them to generate one using:

module_image: generate

if they want the script to generate one using the module name, or they can follow generate with a prompt in quotes like this:

module_image=generate "keywords to use for image generation"

This would mean there are three formats module_image: would support depending on whether and where quotes are used. Without using quotes to differentiate, how would you suggest I let the user ask the script to generate the image for them rather than naming the location of the image?

Thank you for your feedback.

Interesting. Can you give an example? The configuration file we're talking about is what actions the home automation server could take in regards to hearing certain keywords. Suppose you want to add a keyword and the corresponding functionality (what should happen when you say the keyword). How would you like to add it using a JavaScript entry point? (For example what to do in response to a keyword to play a certain playlist.)

    switch(keyword) :
        case "unlock":
            return unlockDoor();

Thank you for the link. It's a new application so I didn't really mean "new format" so much as what you would like to see the configuration itself support. (Maybe I should have said: "when you find that an application has a configuration file, what are the characteristics of that file in terms of functionality and format that you like to see - what do you like to be able to configure in an application and how do you like to be able to configure it using a configuration file, in terms of both structure and functionality?")

You mention "Is it a good idea to still force a single file once the configuration reaches some sufficiently large size?"

If it is not limited to a single configuration file what do you suggest is best practice for which one(s) should be loaded?