On Saturday 18 June 2011 13:16:20 kanenas@hawaii.rr.com wrote:
On Thursday 16 June 2011 11:34:01 pm Will Stephenson wrote:
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.
If we all had pdp-8s and a 2000 entry addressbook, it might be arguable that saving a few k of memory was important enough to change the whole system. In this thread and in many others many have complained about the direction of kde4 and many of us also voted by simply staying out of kde4. In this thread there seems to be a genuine effort to urge developers to go back to simplicity ( from the user point of view) and allow the user more control over system setup. The particular example of the imposed link between kaddressbook and database indexers is a show stopper for me.
As it is for me also. I just can;t use KDE4 for this reason. Bob S -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org