[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-31 13:33:46
[Download RAW message or body]

On Wednesday 31 October 2001 11:48, Rik Hemsley wrote:
> #if Cornelius Schumacher
>
> > - Value based interface, addressbook entry data is implicitly shared.
>
> That's good, but is it thread safe ?

Hmm, I don't know. Is that important? How much of KDE is thread-safe?

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

I think it's a bad thing in this case, because it adds an additional 
dependency without providing extra functionality. It just makes the interface 
more complex and less consistent with the rest of kdelibs. 

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

An invalid entry is returned. You can test for errors with "isValid()".

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

I think restricting write access to one user at a time by locking the file is 
sufficient for preventing conflicts. It means that clients have to check, if 
they are allowed to write data before they change it, but this would also be 
the case with a server. Automatic synchronisation is impossible and a 
user-guided synchronisation isn't in the scope of the address book API.

> Are you still planning on using a single global lock ?

As a first step, yes. I think for an address book, which is typical accessed 
read-only most of the time, this does not cause big problems. If it proves to 
to be too restrictive, we can add per-record-locking.

-- 
Cornelius Schumacher <schumacher@kde.org>

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