Le Dim 2 avril 2006 20:50, Shane Stixrud a écrit : > On Sun, 2 Apr 2006, Nicolas Mailhot wrote: > >>>> Again, if you think the problem is on the user side you've already >>>> lost >>>> it. >>> >>> That's interesting.... others said the problem was on the user side... >>> and >>> you are saying its on the programmers side... >> >> The problem is on the user side >> The solution is on the programmers side. >> >> Which is why analysing the problem from the software writer POW (generic >> API) won't get us anywhere > > Now you are just talking double talk. No. What you absolutely do not want to hear is that system with consistent configuration system APIs are just as bad on the user than Unix configuration files. In fact they are often *worse* because thay make conf file manipulation so transparent for the sotware writer files are cluttered with bad keys and key values. To the point that the *only* way of recovering apps is locate their conf and zap it. As for versionning ROTFL the only sane approach to conf file versionning is thinking *long* before adding a key and not changing its name or semantics every other version. You can add as many software versionning tools as you want the simple fact is if your syntax changes every release no one will be able to keep up with you. Even if you have a massive expert system at your disposal. This is not to say something like elektra wouldn't help a bit, but you're massively overhyping its benefits and underestimating the transition costs. And the fact you're refusing to hear what people tell you does not help you build a solid case. Who cares if elektra is slightly faster than competitors. Who cares is backup is slightly easier. Hardware is getting faster and faster. Humans are not - and right now given none of the pro-elektra arguments is about making human job easier, my feeling is you're massively micro-optimising the wrong place. GConf started much the same way as elektra. I didn't notice it making user or admin life easier. I could be wrong of course. This had been known to happen. -- Nicolas Mailhot -- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-list
