[Kde-pim] Making Akonadi fit for embedded use

[ianseeks]

On Wednesday 31 Oct 2012 10:29:27 Manuel Sput Nickschas wrote:
> 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
A few of us having enough problems with it on the desktop with DBUS errors at 
the moment, lets get it working there first
_______________________________________________
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/