[Kde-pim] Making Akonadi fit for embedded use

Thu Nov 1 14:00:55 GMT 2012

Hey Sput,

That sounds like a great idea and will certainly help to push akonadi 
forward.

For the Kolab Groupware Server (kolab.org) we're planning on getting 
akonadi on the server, for which we will of course face the same 
challenges in respect to the headless environment, as well as we don't 
need the semantic desktop there (at least not yet).

We're also using KDE libraries besides akonadi, but cannot always 
afford to install all of kdepimlibs & kdelibs, especially not in the 
latest version, which is why we're currently working with a copy (not a 
fork!) of the parts we require (http://git.kolab.org/libcalendaring/). 
In the long run we want of course to switch to KDE Frameworks as well, 
and should we get to rely on akonadi for certain tasks, we will need the 
very same libraries you plan to do some work on.

I don't know where exactly you're heading with embedded akonadi, but I 
suppose there are plenty of aligned tasks for future collaboration =)

Find my comments inline.

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

Yeah, I think that should be fine. You will have to make the 
type-specifc subfolders (such as kabc/kcal/...) optional to cut the 
dependencies on the rest of kdepimlibs, but that should be straight 
forward I think (those parts are built as separate libraries already as 
well).

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

Sounds good to me.
libakonadi-core would be a better name IMO, not sure it's worth to 
rename it though.

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

I think a compile-time switch would make sense for things like the 
configuration in resourcebase.cpp.

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

No idea about WinCE, but for the server usecase we'd like to be able to 
disable nepomuk as well, so I think this should be a separate option.
I mean, disabling nepomuk is generally not really a platform dependent 
option, but largely depends on the usecase (nepomuk being available at 
all could be a platform dependend thing though =).

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

As I said, I think it's a great plan from which upstream will profit 
equally, and I hope we will be able to collaborate more in the future.
Don't let the sometimes somewhat slow response time on the kdepim ml 
discourage you, many of the masterminds of kdepim are just very busy. 
They are all very helpful though if you get hold of them =)

Cheers,
Christian

> Thanks in advance!
>
> Cheers,
> ~ Sput

-- 
Christian Mollekopf
Software Engineer

Kolab Systems AG
Zürich, Switzerland

e: mollekopf at kolabsys.com
w: http://kolabsys.com

pgp: EA657400 Christian Mollekopf
_______________________________________________
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/