@graudeejs:
1) In the link I left they kinda try to explain using these arguments:
Speed → This argument surprises me, because even bizarre mobile devices can poke some additional KBs more without an issue (config files are not usually that long and numerous); doing a parse with assumptions and little integrity check is faster, but it's also a glass-like approach: it may break in any moment and can leave application in a non-working state
Complexity → They argument that implementing a parser adds complexity to the code, but truth is that you also have to parse the binaries too
Don't touch it → As different config files have different formats, a user may leave the config file in a non-working state which may affect application startup (see [Complexity], you have to parse and even you can't trust binaries that you vaguely parse || also if something fails and you cant poke the config by in a shell, it also affects the possibility for repairs and it affects application startup like it happened to us here ), so the answer is: discourage from touching it
Config format changes → They mention the problem, but they don't say what it has to do with plain/binary ... this problem applies to binaries too
Update config on the fly → They also mention that if you update a config file you need to notify the app. through some mechanism (which is usually HUP) kinda suggesting that they "take the problem from you"
XML → "really gain from storing configuration in XML. The fact remains that the application must implement a text parser. And in this case the parser must be also an XML validator so the complexity and effort is greater for the programmer. Also, since XML files are either valid or not by definition, it is easy for a non-expert user to make an XML file unreadable after manual editing. A single syntax errors means that the application must reject the whole XML file. This does not happen with traditional UNIX applications which could dismiss lines they do not understand " ↠See the other items
Ecore breaks away from the traditional UNIX approach and offers a configuration API which is based on binary format. While this decision may seem controversial at first, it is actually well thought of.
The only thing I know if something fails/regress (like the splash here) and you don't even provide a terminal interface to modify your binary sweetness ... well, I can't say that it's something "well thought of"
2) Yes, their monolithic approach is really a problem ... because any loaded module can take down the whole wm if something goes wrong with it.
It's amazing that they don't do another process for modules or better yet, one process per module.
Here the module efm (the file manager) takes down the whole wm without mercy, so I'm using thunar
Regards.
