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

List:       kde-pim
Subject:    Re: [Kde-pim] the goal of kaplan
From:       Anders Lund <temp_and () tiscali ! dk>
Date:       2002-10-15 8:41:18
[Download RAW message or body]

On Tuesday 15 October 2002 01:47, Cornelius Schumacher wrote:
> On Tuesday 15 October 2002 01:03, Anders Lund wrote:
> > > In all cases the data should be stored separately from the standard
> > > address book. With the unique IDs and the change signals from the
> > > AddressBook class it's easy to relate data to the addressees of
> > > libkabc. The distribution lists are an example for this concept.
> >
> > I think this stresses the fact that the usage of the .vcf format is
> > problematic. If storing data related to contacts in it is a problem,
> > something is fundamentally wrong, and using a format suitable for
> > that task and exporting vcards on request would be the clever
> > solution.
>
> I don't think that this is a problem of the format. You could express
> everything you want about contacts in vCard. The problem with complex
> data is that storing this into plain files isn't very efficient, you
> would need a real database. This is no problem for people really
> needing that degree of complexity, but for most of the KDE users the
> address book is just a small and simple app for storing some names
> associated with emails, phone numbers, mail addresses and maybe a bit
> more, in most cases probably less.

I can appreciate that:) For one thing, there is no harm in having slightly 
more features in it. If they are unused, they make no harm.

> A database backend is certainly not appropriate for a leightweight
> address book app as KAddressBook should be, so I'm quite sure that the
> current solution is the right one. We have the standard information
> written as simple files in the standard vCard format and everything
> else we can easily add without compromising efficiency for the average
> user.

The problem with the text format is that it is inefficient as soon as you have 
more than a few hundred contatcs. A typical example is that if categories are 
a list of string in each contact, you can't efficiently use them, and 
categories proves more value if you have more contacts. Something a 
database-based approach would solve.

So maybe a more sophisticated addressbook backend for demanding users wouldn't 
be a bad idear after all?

-anders


_______________________________________________
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]