From kde-pim Tue Jun 11 10:51:06 2002 From: Don Sanders Date: Tue, 11 Jun 2002 10:51:06 +0000 To: kde-pim Subject: Re: [Kde-pim] KPIM Workspace X-MARC-Message: https://marc.info/?l=kde-pim&m=102379266615102 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 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/