atom feed21 messages in org.kde.kde-core-develRe: Request for comments: New address...
FromSent OnAttachments
Cornelius SchumacherOct 13, 2001 1:11 pm 
Daniel MolkentinOct 13, 2001 1:54 pm 
George StaikosOct 13, 2001 2:07 pm 
Shawn GordonOct 13, 2001 2:24 pm 
Daniel MolkentinOct 13, 2001 2:30 pm 
Alex ZepedaOct 13, 2001 2:41 pm 
Shawn GordonOct 13, 2001 3:10 pm 
Ellis WhiteheadOct 13, 2001 4:35 pm 
Cornelius SchumacherOct 14, 2001 2:18 am 
Cornelius SchumacherOct 14, 2001 2:41 am 
Rik HemsleyOct 14, 2001 4:42 am 
Cornelius SchumacherOct 14, 2001 6:22 am 
Cornelius SchumacherOct 14, 2001 9:31 am 
Rik HemsleyOct 14, 2001 10:49 am 
Cornelius SchumacherOct 14, 2001 2:50 pm 
Carsten PfeifferOct 14, 2001 3:10 pm 
Don SandersOct 15, 2001 8:02 pm 
Cornelius SchumacherOct 16, 2001 1:31 am 
Don SandersOct 16, 2001 4:28 am 
Cornelius SchumacherOct 16, 2001 7:09 am 
Don SandersOct 16, 2001 4:28 pm 
Subject:Re: Request for comments: New address book API
From:Cornelius Schumacher (schu@kde.org)
Date:Oct 14, 2001 2:18:48 am
List:org.kde.kde-core-devel

On Saturday 13 October 2001 22:54, Daniel Molkentin wrote:

Hi Cornelius!

On Saturday 13 October 2001 22:11, Cornelius Schumacher wrote:

- vCard backend (RFC 2425).

what about mulitple backends? I am particulary thinking of an SQL backend (using Qt SQL). This is especially important for enterprises that already have an existing database or want to share for example a customer database.

An SQL backend would be nice. I don't think this should be the standard way to store address books, but for certain applications it could certainly be very useful.

This is really important if we want to head towards the use of KDE in large offices.

Agreed.

Later on, we could also support importing addresses from Lotus or Outlook (which even shares them via IMAP IIRC).

Import should probably handled on the application layer, not in the lib. For example importing from Lotus Organizer is already possible using the CSV-import of KAddressbook.

As far as I can see from the source, the vcards are dumped into a plain text file.

Yes, you can add different text file formats by subclassing Format. This already has an abstraction layer.

Maybe the possilility of using multiple databases could be useful in this case, too (think of customer addresses vs. employee db).

The API supports multiple address books. There is only a convenience class, which provides a standard address book location.

All this would end up in a backend abstraction layer. What do you think?

This would definitely make sense. I see three possible ways to implement it:

1) Make AddressBook an abstract interface class and move the implementation to subclasses AddressBookFile, AddressBookSql etc. 2) Make AddressBook use a separate backend class, which could then be subclassed to implement different backends. 3) Don't implement the SQL-database as direct backend, but add some mechanism to synchronize the local file with the database.

For 1) and 2) it would be important to implement the SQL backend as some kind of plugin, so that it does generate dependencies on a database only for the people actually using it.

I personally would favor solution 2). This wouldn't require much changes of the API. My main focus at the moment is to get the API right for the applications using it. More sophisticated backend implementations can the follow later, but they shouldn't require changes of the API.