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

[Kevin Krammer]

Am Mittwoch, 2013-10-16, 22:21:17 schrieb Friedrich W. H. Kossebau:
> Hi,
> 
> I recently worked in some bigger FLOSS project (you might guess which, but
> "which" does not really matter here, so just think "XXX" here :) ) on
> upgrading the places where KDEPIM is used, to no longer make use of the
> deprecated KDE3-times KDEPIM API.

Okteda has PIM integration now? ;)

> The last patch/MR had the term "Akonadi" in it a few times, which raised
> eyebrows, as some programs of the project are also (successfully) targetting
> non-Gnu/Linux platforms (Windows/OSX/Android/GNOME/Unity) and "Akonadi" is
> for some reason connotated with bloat & big dependencies ("that needs then
> also a database system and D-Bus? and lots of processes, eating memory for
> breakfast?").

Basically all PIM solutions use a database, even a lot of "just-mail-clients", 
browsers and other applications do.
The main problem with D-Bus seems to be that other platforms seem to be very 
restrictive of overly complicated when it comes to services.
Shouldn't be a problem on OSX, GNOME or Unity though.

> I tried to reason that these days using KDEPIM means Akonadi anyway (at
> least installed), disregard of using the old deprecated API or the new
> Akonadi one, so the patch would not change the existing dependencies (is
> that actually true? :) ), just result in modern use of KDEPIM, so perhaps
> that patch can still go in.

Yes, actually true, to a certain extent :)
One could use the KResource APIs stand-alone when restricting oneselves to 
single file storage, e.g. all entries of an addressbook in a single vCard 
file. No mail access obviously, no groupware access or similar.

And putting onself in the situation of staying with Qt4 technology of course, 
KResource is unlikely to be ported to Qt5.

> 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 :)

I am pretty sure there are other abstraction frameworks out there, QtMobility 
to some extent. No idea how good their abstractions and their respective 
backends are.

The only somewhat comparable FOSS framework is Evolution Data Server and its 
client libraries, AFAIK.

> Q1: Are there such native PIM systems on Windows/OSX/Android actually, so
> that such a abstraction layer makes sense?

I am pretty sure Android has system APIs for PIM data, but I am not sure if 
that is client side only or if they also allow to provide further backends.

I doubt OSX has anything like that, providing services is not Apple's modus 
operandi, other parties could be tempted to create acually useful user 
interfaces.

I think Windows has something conceptually but without any local backends, 
basically just an API to access Exchange if the system is configured for 
exchange.

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

I guess that is actually two questions:
Q2a: Could an Akonadi setup use native APIs? Yes, just a matter of providing 
respective resources

Q2b: Could the Akonadi client API be implemented directly on top of the native 
APIs? Maybe. Probably not with all features. 

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

I don't have any numbers but some heroic people made it work on a Windows CE 
device with absurd limits :)

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

No idea. Probably, things like that get reinvented all over the place all the 
time. Hopefully KF5 and KDE PIM Frameworks 5 can fix that.

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

Use the KDE PIM data classes, e.g. KCalCore types, KABC::Addressee, KMime, and 
develop your data access layer restricted to your specific needs.

Alternatively look how those platforms install frameworks/services, e.g. how 
Windows Games can optionally install DirectX, install Akonadi, and develop 
Akonadi resources for the respective platform APIs and share that work with 
other people :)

Cheers,
Kevin
-- 
Kevin Krammer, KDE developer, xdg-utils developer
KDE user support, developer mentoring
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 190 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kde-pim/attachments/20131017/40595cef/attachment.sig>
-------------- next part --------------
_______________________________________________
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/