From kde-core-devel Tue Oct 30 10:13:33 2001 From: Cornelius Schumacher Date: Tue, 30 Oct 2001 10:13:33 +0000 To: kde-core-devel Subject: Re: Moving new address book API to kdelibs X-MARC-Message: https://marc.info/?l=kde-core-devel&m=100443684703678 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