11–20 of 28 posts
Unless the config file uses JSON as a format. Then no comments for you!
{"height": 100, "width": 150", "__comment__": "This is a comment"}
Of course depending on the implementation details this may keep the comment string in memory. I agree JSON should have native comments, as well as optional trailing commas.
A single problematic XML configuration editor is not a sufficient justification to cling to the morass that a manually-edited configuration file can provide; to paint a whole class of tools. It's probably a better justification for making improvement in the tools you're using; annoyance is a powerful motivator.
If the current configuration editor is insufficient for your needs, consider fixing it.
There are good configuration editors, and there are bad ones, and configuration file errors can run from subtle to blatant, and have definitely introduced legions of errors.
And as with most everything UI in this industry, there are trade-offs between what an experienced user needs or wants here (or the pain such a user is willing to endure, depending on your perspective) and a UI that will utterly drown a new user.
(And these days, and beyond a classic GUI configuration file editor, tossing the underlying configuration file settings into a DVCS certainly has its appeal. Consider the ability to do a git bisect on a buggy startup file, for instance. Possibly through the GUI, or at the command line. )
"There is no good way to put comments into GUI." Maybe he hasn't seen any, but this seems a harsh conclusion. Whoever wrote the GUI could track history of changes, make comments required, and show it in the GUI. There is a vast difference between "there is no way", and "I haven't seen it done right"
It's no where near as simple as comments in a text file, but it's more "user" friendly, where the user is someone other than a programmer.
The primary reason one builds a GUI around a configuration is for guidance. Text based configuration is great if you're accustomed to reading error messages that contain line numbers, but GUI interfaces are able to provide a lot clearer direction for visually oriented people. With a GUI, you can highlight the issues using color, weight, and even motion. You can also provide guidance for correcting the error directly next to the item with the issue.
Earlier quoted context omitted.
JSON is meant to be a serialization language, not a config file language. Therefore it strips out all the things that it doesn't need. If you want a config file language then use YAML which is a much better candidate.
Yes, YAML is very nice. Importantly, it reduces to key:value for the 90% of config files that don't require any hierarchy while still allowing hierarchy if you need it. I'm not sure I buy the serialization argument, though: it's a human-readable serialization format. One of the big advantages of human-readable formats is that you can craft data objects by hand (for automated tests, initial bootstrapping, etc). Commen…
A bigger feature missing in most GUIs is that I can't tell what has changed from the defaults. On the other hand, most text configuration files contain only what has changed from default, which is exactly what I want to know.
The problem is that:
1. Config files need _visible_ defaults
2. Config files need to show current values
3. _Config files need comments_
4. Config files need to be small or they get unreadable
Doing all four is tricky. Postfix gets close:
postconf will show you all config entries. Add -d to get defaults instead. Or try -n to show settings which have been changed.
Even with Postfix you have the big file/comments problem, so what you do is refer to a copy of the original main.cf file, or one stored in the docs under /usr/share/doc/postfix for a thorough explanation of all settings and keep a bare minimum config file with comments in /etc/postfix.
A bigger feature missing in most GUIs is that I can't tell what has changed from the defaults. On the other hand, most text configuration files contain only what has changed from default, which is exactly what I want to know.
I would say the biggest problem with text configuration files is that you can't ever be sure what the default is. The problem is that: 1. Config files need _visible_ defaults 2. Config files need to show current values 3. _Config files need comments_ 4. Config files need to be small or they get unreadable Doing all four is tricky. Postfix gets close: postconf will show you all config entries. Add -d to get defaults i…
Arguably defaults are always there, whether configurable or not. Thus you cannot claim to be familiar with an application unless you know how it behaves in its default configuration (whether that is in a GUI or a text file).
I think this is fundamental and not an issue that configuration (text, GUI or otherwise) needs to deal with.
> 1. Config files need _visible_ defaults
I agree, but I don't see that this should be in the config file. I do think that there should be a way to see what these are. Your postconf example is perfect for this.
Like you, I'm in favour of keeping the bare minimum config file only. Comments should only describe something local about the site (just like "i += 1 # add one to i" is wrong). Documentation of configuration variables should be somewhere else.
Earlier quoted context omitted.
I would say the biggest problem with text configuration files is that you can't ever be sure what the default is. The problem is that: 1. Config files need _visible_ defaults 2. Config files need to show current values 3. _Config files need comments_ 4. Config files need to be small or they get unreadable Doing all four is tricky. Postfix gets close: postconf will show you all config entries. Add -d to get defaults i…
> I would say the biggest problem with text configuration files is that you can't ever be sure what the default is. Arguably defaults are always there, whether configurable or not. Thus you cannot claim to be familiar with an application unless you know how it behaves in its default configuration (whether that is in a GUI or a text file). I think this is fundamental and not an issue that configuration (text, GUI or o…
I don't agree with this part. The best way of learning about a program is to play with it. Knowing how a program is expected to behave is key, and without defaults you don't.
Even if someone knows the defaults, they will change.
(I agree with the rest of what you wrote)