[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:       Cornelius Schumacher <schumacher () kde ! org>
Date:       2001-10-30 10:13:33
[Download RAW message or body]

On Tuesday 30 October 2001 04:02, Mirko Boehm wrote:
> 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.

The backend is not very relevant in this context. Implement another one, if 
you are not happy with vCard. The new API mainly addresses the _API_ 
problems, not the backend problems.

The reason I chose vCard as backend is that it is designed as a storage 
format for addressbook data, it is extensible, it is useful as an interchange 
format, it is standardized (RFC 2426) and it is widely used. Most of these 
things are not provided by libkab. How do you come to the conclusion that 
this is a step back? I don't get it.

API-wise the new API provides a lot of improvements over the old one:

- Value based interface, addressbook entry data is implicitly shared.
- Clean separation of GUI and data handling (in libkab you had to instantiate 
a widget to get access to the data)
- No more dependencies on STL
- Results of functions are delivered as return values not written in 
references passed as function parameters
- Functions to set and get data, no public variables like libkab had them.
- Classes are cleanly namespaced (libkab had e.g. a class AddressBook in the 
global namespace)
- Backend details are not exposed in the API.
- Clean way to add custom entries, preventing conflicts of entries added by 
different applications
- Well-defined way to handle different types of phonenumbers, addresses etc. 
(who ever has tried to get e.g. a fax number from libkab, knows what I'm 
talking about here)
- Support for distribution lists implemented as extension, which does not add 
overhead to applications not using this feature.
- Dialog for selecting address book entries supports mouse and 
keyboard selection, supports automatic name completion.

> 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.

Porting the applications will be a matter of a few days. I already have 
ported Kandy and it took me less than an hour. I'm not aware of any features 
that the old API had and the new API does not have. Which features do you 
mean? The conversion tool for converting old address book data to the new 
format exists and works fine.

I don't see a problem here. You are right that the new lib needs more testing 
in real life, but how is this supposed to happen, if we don't use the lib? 
Moving it to kdelibs and porting the apps is exactly the right step to get 
this testing.

> 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

We have to make one step after the other. The new address book API only 
addresses the problem that we currently don't have a nice programming 
interface to access address book data in KDE. Without that all further steps 
to a more global PIM solution will fail. The new address book API does not 
pose any restrictions on further developments.

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

I'm not rushing anything. The new API was carefully designed, discussed, 
implemented and tested. It is feature complete and we still have a few months 
left to fix the remining problems which might occur, when it is used by more 
applications.

-- 
Cornelius Schumacher <schumacher@kde.org>

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