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

Thu Oct 17 21:57:05 BST 2013

Hi Andras & Kevin,

thanks for your detailed answers.

Am Donnerstag, 17. Oktober 2013, 10:01:20 schrieb 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? ;)

Hehe, I knew there are clever people here ;)
Now, since ages even, see
http://api.kde.org/4.3-api/kdeutils-apidocs/okteta/html/classPerson.html
(left-over from early experiments with realtime-collab, really) :P

And interesting to learn the austria localization of Okteta :)

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

Windows (sadly) is important for the programs in case.

> > 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 most important no integration still with any possible platform PIM system, 
so no real advantage. Need would be to feed/fetch data to the existing data 
pools, not create an own data pool.

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

He, Qt5 needs porting? ;)

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

Client only would be fine. Anything where the usual data is.

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

:) (But did they then not simply buy them into their corpus^Wcorporation a few 
times?)

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

Okay. Possibly any possible simple system connection plugins would then just 
target one dedicated system, like Mozilla DBs. Better than nothing.

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

So KCalCore types, KABC::Addressee, KMime are usable independently of the 
current storage interfacing system, i.e. Akonadi? Very good.

Because seems I am looking for something that is the "Phonon" API of PIM.
A simple API for the most typical simple usecases (picking an event/contact 
from existing ones, creating a new event/contact, picking a message, sending a 
message etc).
No built-in caching mechanism in that layer. The backend may do that, very 
fine and lots of reason to do so, but that should only start behind the 
respective plugin to the abstraction layer, not already before (looking from 
API user side).

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

Well, I personally do not really care about platforms outside of Gnu/Linux and 
rather want to have an as strong as possible integration with the KDE 
libs/systems. But as the same time also want to avoid unneeded conflicts with 
those who rather look (for several reasons) into other platforms, and thus 
make sure they can happily interface with whatever they have there, without 
getting big deps just because of my KDE PIM addiction.
Meaning: no code from me for those platforms, unless paid ;)

Okay, so one part is answered, no real thin PIM abstraction layer known which 
simply could be used. 

For the other part I still need a definite answer:
If code continues to use the old deprecated API and uses 
KCal::CalendarResources and KABC::StdAddressBook::self(), will that code have 
access to all the resources which are bound in via Akonadi? Or do the old 
resources create a different collective pool if accessed via the old API?
So if I configure the event/contact Akonadi resources via KOrganizer and 
KAddressbook, will those (Akonadi-style?) resources still be listed and 
accessible via the old KResource API?
Or are the old KResource resources both readable by the KResource system and 
Akonadi, but Akonadi resources not from the KResource system?
So, will porting to the new API actually fix a problem in not being able to 
access the newer Akonadi resources? So bringing a value besides getting rid of 
all the deprecated warnings during the build?

Cheers
Friedrich
_______________________________________________
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/