On Wed, May 27, 2009 at 12:10:54PM -0500, Boyd Stephen Smith Jr. wrote: > >It's > >something hidden from the user instead of telling them about > >it. That's never a good idea. > > Actually, according to actual HCI studies it is often better to hide things > from a user instead of telling them about it.
What means "better" in that case? > Now, once the user starts > looking for that setting, it should be available, but too many settings and > too much explanatory text confuses rather than enlightens. Whatever you do, there's nothing that helps against stupidity. > >> >> These same issues can be hidden when using RDBMS backed, but the > >> >> translations are usually much faster. > >> >Both of these won't be human readable, plain text files. > >> Actually, yes. KDE Configuration files are human-readable, plain-text > >> files. They aren't free-form prose. For the most part they follow the > >> ".desktop" file specification put together by XDG. > >If you have to make so many "translations" of a configuration file > >that nowadays' computers run into performance problems when doing so, > >I don't consider the file as a human readable configuration file > >anymore. > > I never said the translations were causing performance issues. I > said they'd be faster with an SQL backend. That is definitely *not* > the reason Akonadi wants an SQL backend. Then it's irrelevant that translations can be "usually much faster" when an RDBMS is used. > They are quite readable. Usually a translation is just changing the > name/spelling of a key. But, it might be converting a value that is a list > into multiple stanzas or something like that. Generally, they leave the > values alone, but they are the migration path from 'old' configuration files > to 'new' configuration files. So these translations need to be done only once? > >> >Try to read > >> >your current kde configuration in 35 years, or try to read your data > >> >from the the RDBMS you're currently using in 35 years. You'll find > >> >that it won't be easy. > >> I hope so. I plan on using different, hopefully better, software by > >> then. > >And what if you need the information stored in it? > > I won't. I'll export the data as I abandon that software. Actually, I'll > export the data before I abandon the software so I can import it into the > new software and test it. That is a possibility, but it requires to plan for it and to work on it, and mistakes can be made. It would be easier if that wasn't required. -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
