|Cornelius Schumacher||Oct 13, 2001 1:11 pm|
|Daniel Molkentin||Oct 13, 2001 1:54 pm|
|George Staikos||Oct 13, 2001 2:07 pm|
|Shawn Gordon||Oct 13, 2001 2:24 pm|
|Daniel Molkentin||Oct 13, 2001 2:30 pm|
|Alex Zepeda||Oct 13, 2001 2:41 pm|
|Shawn Gordon||Oct 13, 2001 3:10 pm|
|Ellis Whitehead||Oct 13, 2001 4:35 pm|
|Cornelius Schumacher||Oct 14, 2001 2:18 am|
|Cornelius Schumacher||Oct 14, 2001 2:41 am|
|Rik Hemsley||Oct 14, 2001 4:42 am|
|Cornelius Schumacher||Oct 14, 2001 6:22 am|
|Cornelius Schumacher||Oct 14, 2001 9:31 am|
|Rik Hemsley||Oct 14, 2001 10:49 am|
|Cornelius Schumacher||Oct 14, 2001 2:50 pm|
|Carsten Pfeiffer||Oct 14, 2001 3:10 pm|
|Don Sanders||Oct 15, 2001 8:02 pm|
|Cornelius Schumacher||Oct 16, 2001 1:31 am|
|Don Sanders||Oct 16, 2001 4:28 am|
|Cornelius Schumacher||Oct 16, 2001 7:09 am|
|Don Sanders||Oct 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|
On Saturday 13 October 2001 22:54, Daniel Molkentin wrote:
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.
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 <schu...@kde.org>