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

List:       kde-core-devel
Subject:    Re: Moving new address book API to kdelibs
From:       Mirko Boehm <mirko.boehm () home ! com>
Date:       2001-10-30 3:02:43
[Download RAW message or body]

Cornelius Schumacher wrote:
> 
> I would like to move the new address book API from kdepim/kabc to
> kdelibs. This also requires that the vCard lib is moved to the libs
> (kdepim/vCard). The test GUI client (kdepim/kabc/frontend) should stay
> in kdepim.
> 
> When the code is moved I will start porting the applications to the new
> API, starting with kaddressbook. When all applications are ported, I
> think we should disable installation of libkab and only link it to the
> conversion tool for old addressbooks.
> 
> Any objections?
I hate to write that email but I tried my very best. I talked to
Cornelius in a number of emails regarding this matter, to explain to him
why I think the move he wants to make is a step back.

I basicly think his approach does not provide anything better than the
current one, but limits us by using the vCard format in the backend.
vCards are designed as a common denominator for data interchange and by
this do not provide the features for a decent contact database support. 

Additionally, the library has not been tested in real live except a
small and customized example application. Regarding that KDE 3's feature
freeze is right around the corner he will never be able to port the
applications needed - while extending his library for the missing
features - and provide our existing users with conversion tools that
ensure data consistency in time. 

While I agree that we need something new regarding the PIM api, I think 
- this is not the right step 
- it will push us back a long leap just implementing what is already
there 
- we need an approach that spans more than the local contact storage
(basicly all other pim applications in a concerted approach) to get out
of the KDE PIM mess

Sorry, Cornelius, but I think rushing in with something definitly not
mature is the wrong way.

CU all,

--Mirko.
-- 
I am wrong.

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