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

[Will Stephenson]

On Monday 06 September 2010 14:42:39 Gregory Schlomoff wrote:
> First of all, thanks a lot for all the replies.
> 
> Yes, as Tobias pointed out, I wasn't very aware of the difference between
> Akonadi server and the access libraires. I guess that what Will refers to
> as 'akonadi the middleware' is another term for the access librairies.
> 
> "Akonadi" was an unclear concept in my mind, and as we all know, unclear
> concepts are the root of all evil. Now, what I've understand is that there
> is :
> 
> - Akonadi server, that provides local storage / caching for PIM objects in
> a MySQL database.

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

> - Akonadi middleware that uses Akonadi server to store / retrieve data to
> and from the local cache

I used the term 'middleware' loosely here to refer to 'the server and the 
access libraries'.

Disclaimer: I'm an Akonadi user (as sometime resource and client app developer 
and end user), packager (for a Linux distribution) and friend of the project, 
but I'm not an active developer of the server itself, so take me with a pinch 
of salt.

> To make things clear, our most basic needs are :
> - to be able to fetch emails from an IMAP server
> - to store them to a local cache, and to retrieve them from the cache
> - to do all this in the most elegant and simple way, without relying on
> KDE

> 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).
 
> So the path that we're planning to adopt is the following:
> 
> 1. Build Akonadi server on windows, without KDE dependencies (so that
> should be the easy part, if I understand well, as this is already the
> case.)

This should indeed be easy.

> 2. Port the Akonadi agents that we're interested into, and their
> dependencies. That would be at least KIMAP, KJob, and KMIME, possibly a
> bunch of others. For the first three, we've already done part of the job.

Just in case the concepts aren't clear: The term 'agent' in the Akonadi book 
refers to a helper process that inputs data to Akonadi or processes data.  
Examples would be an IMAP resource, a Google Data resource, an indexing agent 
or an SMTP mail transport agent.  The term 'resource' is a specialisation of 
'agent', one which only provides access to data stored in a particular way.

> 3. If everything goes well, we should be able to start an instance of
> Akonadi server in a different D-Bus session, as Kevin explained, and
> interact with our server from our app.

Sounds reasonable (see disclaimer above)

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

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.

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

HTH

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