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

List:       kde-core-devel
Subject:    Re: Request for comments: New address book API
From:       Cornelius Schumacher <schumacher () kde ! org>
Date:       2001-10-14 9:19:10
[Download RAW message or body]

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.

-- 
Cornelius Schumacher <schumacher@kde.org>

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