[Kde-pim] Using Akonadi on other platforms than KDE

[Gregory Schlomoff]

>
> It supports other databases including sqlite and postgres - mysql is the
> most
> widely used one.
>

Does it really supports sqlite? From what I've read, it seemed more like a
goal than an actual feature. But that would be very good news, I'm a little
bit concerned by having to run a whole MySQL server for my app.


> > or even on the fact that an instance of Akonadi server is running on
> > the machine.
>
> Running Akonadi server on a remote machine has been considered (for cases
> like
> thin clients) but is not currently a priority for the project, so to make
> this
> happen you would need to tweak connection settings (Akonadi's mysql is
> currently setup to connect using only a local socket) and make sure the
> security settings meet the needs of a remote client(s).
>

I haven't been clear here. What I meant was not "Akonadi may be running on a
remote machine" but instead "We can't assume Akonadi server is available on
the machine, like it is on KDE. We need to ship and manage our instance of
Akonadi server so that our app works out of the box on Windows, Mac, and
Linux"



> > Does it all sounds realistic ?
>
> It's realistic. But while I appreciate that you've already done a ton of
> work
> in de-KDEing kimap, kmime and kjob, with my 'more shared is better'
> mindset,
> it seems that this forking all the resources and their dependencies to
> strip
> out KDE is more work in the long term and makes sharing future developments
> harder


Let's make things clear, once and for all : I *hate* forks. Managing a fork
is a pain, and I want to avoid this at all costs. I have forked kimap,
kmime, and kjob as a quick and dirty proof-of-concept, at a time where I had
no experience with Qt, and barely any experience with C++ at all. Now, I'm
looking for the good, right, and elegant solution.


> harder than building kdelibs in a stripped down version and shipping that
> as
> part of your client's stack.  kdelibs is already pretty modular, and I
> expect
> that this is the approach being taken by the Kontact on Mobile (including
> WinCE) project.
>

I was not aware of this possibility. That's exactly the kind of advice that
I am looking from this mailing-list. Would you mind elaborating on this, or
pointing me to the right resources?


> You also need to decide how to do non-trivial mail search and indexing.  In
> the Kontact space this is done by an agent passing data to auxiliary
> Nepomuk
> semantic search and full text indexing process (massive understatement) but
> this may also be a dependency bundle too far for you.  I don't know how
> Kontact on Mobile handles this.
>

Searching and indexing is actually where the core of our value proposition
is, so that's something we want to do ourselves.


>
> > As for the licence issues, is everything LGPL'd? Our project is
> commercial,
> > but obviously we would be releasing back all the work done in order to
> get
> > this setup working.
>
> Never take anyone's else's word that anything you are betting your project
> on
> is unproblematically licensed unless they are your licensing and IP lawyer.
>
> All I'll say is that Akonadi is structured to be friendly to many licensing
> and coding approaches. Do your due diligence.
>

:) straigth and clear answer

So the bottom line is: As of now, I still have very litle knowledge of
Akonadi. I'm studying the various ways to use it. I hope now you guys have a
clearer understanding of my problem and what I'm trying to do. Every advice
/ suggestion / etc... is highly appreciated.

Thanks,

Greg
_______________________________________________
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/