[Kde-pim] Making Akonadi fit for embedded use

Manuel "Sput" Nickschas sputnick at quassel-irc.org
Wed Oct 31 09:29:27 GMT 2012


Hi all,

As people frequenting #akonadi already know, I'm currently evaluating the use 
of Akonadi for an embedded Linux platform. There's a few things that would 
need to be done before I can consider choosing Akonadi for my usecase; I've 
had some fruitful discussions with people on IRC already, so I think it's all 
feasible and in upstream's interest, but I'd like to reiterate the points on 
the mailing list as well in order to get feedback on how to start.

Note that I will be able to devote quite a bit of time into actually working 
on these things in the next few weeks; so I'm not requesting people to do my 
work here, though help will of course be welcome :)

Prerequisites
==========

This is an embedded platform with no graphical environment, i.e. no X11. I am 
interested in using both akonadi-server and libakonadi on the middleware layer 
only. This means we need to cut out dependencies to X11 as well as to KDE 
runtime (and generally try to keep dependencies really low). I would also like 
to not use semantic desktop things, even though that obviously would mean that 
I lose some features.

It follows that we can only consider to use KDE Frameworks, as we'll have 
neatly split dependencies there. Stephen Kelly was already nice enough to 
rebase kdepimlibs' frameworks branch, and I managed to build the interesting 
(for me) parts of kdepimlibs against KDE frameworks last week with only a few 
hacks and workarounds (that of course need to be done properly). So, this 
seems to be already in a close-to-usable state, thus feasible for my purposes.

Things that need to be done
=====================

Some of the things I see myself working on in the next few weeks, and please 
give me feedback if it's aligned with upstream's plans or completely stupid:

* Provide a cmake option for kdepimlibs for only building libakonadi. There's 
already something like this for kleopatra, so this should be not too 
controversial?

* Split away a libakonadi-widgets library that contains, well, the widgets (or 
QtGui dependent) stuff, thus making libakonadi-kde (should that maybe called 
libakonadi-core instead?) free of X11 deps

* Even without widgets, there are still some QtGui deps in both akonadi-server 
and libakonadi for things like window IDs for configuration. Not sure how to 
handle that one; maybe another build option?

* Make Nepomuk and friends optional again. It seems they're still optional for 
WinCE; I wonder if the WinCE case should be generalized to a build option for 
embedded use in general? There's tons of WinCE related exceptions in the cmake 
files which I think would be desirable for other embedded platforms too.

End goal
=======

So this is where I would like to arrive in, say, a month's time (with me 
working more or less fulltime on this; note that my familiarity with the 
codebase is rather limited still, though I do know my ways around Qt and 
CMake):

* An Akonadi server that does not depend on QtGui and friends.

* A libakonadi-core (or -kde; I like the other naming better since it conveys 
the purpose better) that is free of QtGui deps, only links to tier1 libs from 
KDE Frameworks (e.g. kcoreaddons for KJob) and does not require pulling in all 
the semantic desktop stuff. This library should contain all the neat things 
required for writing agents, accessing the server, and the models.

* If possible, all should be properly supported upstream by having cmake build 
options to achieve this without carrying patches around.

* Doesn't need to be production ready (i.e. I don't need KDE Frameworks to be 
released ;-)), but it should be usable enough to demonstrate that the approach 
works for our purposes. This includes deploying it on the embedded platform, 
which is why getting the build system stuff done is one of the more important 
bits.

Closing
======

Well. Comments? Am I out of my mind, or am I pursuing something that upstream 
wants too and that's feasible? Any good pointers on where/how to start?

Thanks in advance!

Cheers,
~ Sput
-- 
Manuel "Sputnick" Nickschas ("Sput" on Freenode)                  |  (o<
Member of the Quassel IRC Project - http://quassel-irc.org        |  //\
Come visit us in #quassel!                                        |  V_/_
_______________________________________________
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/



More information about the kde-pim mailing list