[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-pim
Subject:    Re: [Kde-pim] KPIM Workspace
From:       Don Sanders <sanders () kde ! org>
Date:       2002-06-11 10:51:06
[Download RAW message or body]

Heh, the seperate files question. Similar to the mbox vs maildir 
choice in a mail client.

On Monday 10 June 2002 22:20, Cornelius Schumacher wrote:
> On Monday 10 June 2002 20:10, André Somers wrote:
> > Which brings me to the question: is there a reason why all VCards
> > are stored in one file, and not using one file for each contact
> > (with an index file maybe)?

I guess I have spent quite some hours working on optimizing KMail code 
for loading large mail folders and you are essentially trying to 
solve the same problem.

Ok, from KMail experience KAddressbook doesn't need to load all 
address book entries, it only needs to load kabc::addressee that are 
visible. That is in the QListView view, loading of a kabc::addressee 
can be delayed until it's actually painted in 
QListViewItem::paintCell (or the QTable equivalent).

This is massive gain because if you have 1 million entries in the 
addressbook and only ten are visible then you only have to load the 
10 visible entries.

The technical problem here is that you need to keep a sorted index 
file for at least the field that the address book is currently sorted 
by, and if you can spare the disk space consider doing it for all 
sortable fields. This sorted list needs to be kept up to date as 
items are inserted, deleted and modified, a simple QValueList<QString 
= uid> should be fine for up to a million items on modern machines.

IMO KAddressBook should be responsible for maintaining (saving, 
updating, loading) this (these) sorted index files.

All kabc has to be able to do is quickly return an addressee given 
it's uid. You could use the maildir approach here, use a seperate 
file for each vcard, name each vcard file after its uid and let the 
filesystem do the work.

I wish some of the kmail code could be reused for this, but that's not 
trivial. (And the KMail code still needs some work, as it's sorted 
file was written before KMail had uids for messages).

Alos it's a pity that kabc uids are QString, ints would be more 
efficient but nevermind.

> There is no real reason other than that it's simpler to write a
> single file than one per entry and that an addressbook contained in
> a single file is simpler to handle manually.
>
> > My guess is that it would make saving much faster, but it might
> > slow down loading. Correct?
>
> It will certainly make saving much faster. I don't think it will
> significantly slow down loading.
>
> I think we should think about separating the addressbook into
> multiple files. This has some advantages, but on the other hand
> it's an implementation detail which should be hidden by the API and
> at the moment the priority should be to get the API right.

Well it works ok for maildir.

About the unified application idea. I've long been for it. Ultimately 
I would prefer to use only one application that is constructed from 
reusable parts and perfectly customized for the way I work.

Having said that, even though I'm completely for it, I don't think 
unifying KMail, KOrganizer, KAddressbook is going to buy you that 
much. The main advantage I see is that you can start up all the 
applications with only one click.

I agree when people ask for a unified application they are normally 
asking the wrong question and instead they would be better off asking 
for a specific features. (Like categories, or full text search index 
or whatever).

Gotta go,
Don.

_______________________________________________
kde-pim mailing list
kde-pim@mail.kde.org
http://mail.kde.org/mailman/listinfo/kde-pim
kde-pim home page at http://pim.kde.org/
[prev in list] [next in list] [prev in thread] [next in thread]