User software configuration, why doing it?

Surprisingly some people where silently interested in the standard about configuration of user software. So I added some chapters and restructured the document a little bit. Just in case.

There’s still a lot specification-work to do. Most people probably can’t imagine why. Others simply start implementing. I don’t think the approach will work for this. But anyway, if people want to do that they should.

In my humble opinion can’t the configuration problem be solved by just hacking together an implementation. In fact aren’t the proposed solutions solving any real problems. GConf and KConfig solved those problems already. Unifying them is a.t.m. pointless. And actually as the proposed solutions introduce yet another ad-hoc standard, they in stead add to the problem.

More about this and also read this.

ps. I might soon also post some UML class diagrams of the current idea I have for the reference implementation of the service. I also have some working experiments. Vaporware–, it’s more about popping todo items.