[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:       Rik Hemsley <rik () kde ! org>
Date:       2001-10-31 10:48:38
[Download RAW message or body]

#if Cornelius Schumacher
 
> - Value based interface, addressbook entry data is implicitly shared.

That's good, but is it thread safe ?

> - Clean separation of GUI and data handling (in libkab you had to instantiate 
> a widget to get access to the data)

Good.

> - No more dependencies on STL

I used to think that using STL was a Bad Thing, for these reasons:

1. Some developers only know QTL.
2. Hassle interfacing between STL and QTL.
3. STL support may not be consistent across platforms.

Now 1. and 2. aren't really issues any more. I don't know about 3.

> - Results of functions are delivered as return values not written in 
> references passed as function parameters

How are errors returned ?

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

All good.

Still, what about locking/synchronisation ? As Mirko says, without a
central server, synchronisation is a nightmare.

Are you still planning on using a single global lock ?

Rik

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