[Kde-pim] Akonadi questionez

Kevin Krammer kevin.krammer at gmx.at
Fri May 21 20:21:50 BST 2010


Hi Jos,

On Monday, 2010-05-17, Jos Poortvliet wrote:
> Hi fellow gearheads,
> 
> The marketing team asks for your help in communicating Akonadi.
> 
> You might all be aware of the questions often seen on mailinglists,
> like "what the heck does this resource hog do here" and similar
> insults. Basically, the users are asking:
> 
> 1. what does it bring me NOW

This is the hardest question, also because it depends on what "NOW" refers to.

As of KDE SC 4.4 there isn't really a lot positive for users to actually 
notice other than maybe access to Google contacts through the Google 
connector.
Unfortunately this connector is limited in certain ways, e.g. which contact 
fields it supports, so this might count more as a thing to play with than a 
thing to work with.

As for KDE SC 4.5, well this for one depends on when in the 4.5 cycle KDEPIM 
will be ready for release and it might also be just improvements on certain 
data transports, e.g. I think there is a very functional CalDAV connector 
which can talk to most calendar servers out there.

Most of the time related to Akonadi had to be spent on massaging insanely old 
and complex code bases on top of something that is totally different in almost 
all aspects to whatever these applications had been using before.

So while an Akonadi based e.g. email setup as done with KMail2 could offer 
folder specific cache settings (current KMail can only do account specific, 
same for all folder of an account and not changable without account 
recreation), I am almost certain that there is no UI for that yet.
(somebody please correct me if I am wrong on this one).

Other improvements such as not having to run KMail when working with groupware 
contacts or calendar such as Kolab is only visible to such users of such 
setups, which probably means only a tiny group outside the company/public 
administration camp.
 
> 2. what problems does it solve?

Right now mostly engineering problem such as getting rid of hack on top of 
hack that where added during more than ten years of development.
It allows KDEPIM developers to look forward instead of watching their backs, 
allowing to cope with requirements that have been unseen at the time 
applications like KMail or KOrganizer were designed first.

It also makes it possible to split things into more module parts making it for 
one possible for other application developers to do PIM related stuff from 
withing their applications (e.g. sending reminder emails from invocing 
applications) as well as enabling "light" versions for use in mobile 
scenarios, etc.


> 3. what will it bring me in the future?

For one, more variety on data sources. We already see much more new 
contributors working on Akonadi resources (data source connectors) than at any 
time before, mostly because working on these can now be done without having to 
muck with specific application code bases (see above).

Another one depends on whether other application developers will use this non-
applications specific approach to enhance their applications with related 
functionality.

Some early attempts have already shown potential for unprecedented workspace 
integration, context/activity aware new-mail notifications, dragging PIM 
objects to your desktop but keeping them live-updated and so on.

> Meanwhile, the promo team is struggling with this. We know *part* of
> the answer, but still would like to solicit input from those great
> minds which came up with it in the first place!

Unfortunately this is mostly something at developer level right now as far as 
improvements go.
A bit like in early Plasma days when people would complain about things not 
working as expected and mainly developers-only knowledge about what will be 
possible due to all the new infrastructure thats in place now.

> Moreover, I think it would be a good idea to extend the information to
> a call for help. So do you want help and if so what kind of help
> (testing, documentation writing or other relatively simple jobs, are
> there programming jobs to be done etc) do you want.

I think the main task aside of development will be documentation.
Things will work differently with Akonadi, since no single application is in 
control of a certain aspect of PIM, e.g. KMail will be the GUI to mail, not 
the things sending or receiving it.

While all functionality should be there just like it was before, common 
workarounds or usage patterns might no longer fully apply.

Cheers,
Kevin

-- 
Kevin Krammer, KDE developer, xdg-utils developer
KDE user support, developer mentoring
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 190 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kde-pim/attachments/20100521/79657b65/attachment.sig>
-------------- next part --------------
_______________________________________________
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