[Kde-pim] (KDE)PIM abstraction layer on non-Gnu/Linux systems?

[Andras Mantia]

Hi,

Friedrich W. H. Kossebau wrote:
> But I was asked if for those non-Gnu/Linux systems there is not another
> abstraction layer which would use whatever native PIM system there might
> be. Which I have to forward to you as the KDE PIM experts :)
> 
> Q1: Are there such native PIM systems on Windows/OSX/Android actually, so
> that such a abstraction layer makes sense?

Sorry, can't answer this. I'd assume for Android there isn't any specific, 
it uses the Google services.

> Q2: Would Akonadi still be a proper abstraction layer to them?

I'd say, that for KDE applications, yes. If there is a native calendaring 
system/adressbook, the solution is to make that available to Akonadi, so any 
KDE application can use it.

> Q3: What is the most slim possible usage of Akonadi, what are the min.
> requirements?

Qt, D-Bus and an SQL server. Can be SQLite, although I vote against it. :)
In theory the dbus dependency can be exchanged to some native IPC, but that 
needs changes both in Akonadi server and the client libraries.

> Q4: Is there any simple Qt/kdelibs-based abstraction layer to native
> contact/calendar/email systems known (not Qt Mobility)?

I don't think there is.

> Q5: What else would you recommend to developers who want to provide their
> KDE programs as stand-alone packages on those system and have some
> read/write access to the system's PIM data?

Akonadi. :) The whole point of Akonadi was to allow apps to share the same 
PIM data and to remove duplicating of code all around the applications.
If applications want, they can start again to fetch/save, read/write and 
interpret the PIM data using some of the existing libraries (after all 
Akonadi is also using those libraries), but that would be quite some 
duplicated effort.

Andras
_______________________________________________
KDE PIM mailing list kde-pim at kde.org
https://mail.kde.org/mailman/listinfo/kde-pim
KDE PIM home page at http://pim.kde.org/