On 17/06/11 01:31, Anton Aylward wrote:
Stan Goodman said the following on 06/16/2011 05:28 PM:
Unfortunate that no more conventional address book is supplied for kamil, for the benefit of people who only want an address book rather than a magic genie.
Good point, Stan. And it makes me wonder, why invent a new addressbook database?
There is no new addressbook database. Your default addressbook continues to be stored in standard VCard files. A database is only involved as an implementation detail of a PIM data service. A PIM data service is part of a design to reduce memory footprint, startup time and avoid concurrent access issues, which you can have as soon as you start using KMail and KAddressbook simultaneously. <snip>
But there is a deeper issue here. Microsoft moved from individual config files to the "Registry". I can turn to almost any config file under Linus and there is embedded text documenting the settings. Some files are stripped, but templates or detailed man pages exist. The Registry, by comparison has no inline documentation and external documentation is often difficult to find or non-existent.
The comparison is ambiguous because we're talking about data here, not configuration and invalid because KDE PIM data is still stored in the standard text based format, not in a binary database. Old model UI (eg Kmail) <---> Some APIs, custom per-application database code, ioslave processes, which you have to read the code to understand <---> standard text based data files New model UI <----> Some APIs, common database process, also opaque <---> standard text based data files The difference is that in the old model, as soon as you have more than one UI accessing the data (eg KMail and KAddressbook) all the data and access code is copied into memory linearly times the number of UIs. In the new model, more of that is shared. In the new model, all the ad-hoc 'database' implementations are replaced with one dedicated database used as a cache to save all those in-memory copies of the data from the disk. For reference T'bird: UI <---> Some APIs <---> Mork database file ( ~/.thunderbird/*.default/abook.mab) which if you cat it out is text, but harder to work with than vcard. Evolution: UI <---> Some APIs <---> dbus server <---> e-d-s custom database instance <---> sqlite and berkeley DB files So the grass is no greener there.
My fear is that too many things in Linux are moving to that centralised database model.
I'm sorry that the windows registry and gconf have poisoned the well of user goodwill for Akonadi. If you look at how the KDE PIM team are doing a service based architecture, you'll see that they are striving to preserve users' control of their data. The problem is that users, who don't need to understand any of the bits between the UI and maybe the data files, see "DATABASE" and equate that with "BLACK HOLE"
My second fear is that many things (much of KDE config is one example) that the config is only documented in the source code and not the man pages.
I hope that a look inside /usr/share/kde4/config.kcfg/ 's files will allay that fear. Since KDE 3, KDE has used these commented definitions of the apps' config data schemas. There was the kconfigeditor tool to browse and modify configuration too, but that seems to have been left to rot, and unfortunately no-one ever wrote a kcfg->man page formatter for you. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org