I'm finally spending most of my time on KDE 4, and now that I have the RC running, I'm thinking it's time to switch over my PIM stuff.

Now, the great, groundbreaking thing in KDEPIM is supposed to be Akonadi. From what I've read, some of the things it does is let me index my stuff with Nepomuk and let me use different clients at the same stuff. I only use KDEPIM, so that does not really matter, but I wouldn't mind the Nepomuk part.

However, from what I'm seeing right now, it feels like a hassle.

Let me start with the calendar. I have several calendars - my personal calendar, my schedule, and a few remote university calendars. In KDE 3, I'd have a little list of calendars, each with their own colors, with checkboxes next to them. I could of course do the same thing with KOrganizer4, but then I'm not using the Akonadi resource. If I use it, they get all grouped under it, with the same color, and called something as useless as akonadi_ical_resource_14, which gives me absolutely no hint as to what they are.

Same thing with addressbook - akonadi_vcard_resource_1 is absolutely meaningless to me. And there's no way to change it.

I also had an impression that Akonadi had a large part about mail. So I think, great, now my mail will be managed by something else, so I'll be able to put it somewhere other the depths of the .kde directory. Nope, everything's the same. All the mail goes in the same place.

Which makes me wonder, what is this Akonadi thing for? Is it just not at the stage where it integrates well with Kontact, like Nepomuk was in 4.1? Or am I just misunderstanding it and missing the whole point? Could someone please explain to me how it is useful?

Alec wrote:Is it just not at the stage where it integrates well with Kontact, like Nepomuk was in 4.1?

That's basically the main reason.

We (as in KDE PIM developers) didn't have enough time to port most of our applications for Akonadi usage yet (the KPilot people managed to do it already).

At our annual meeting last week in Osnabrück, Germany, we discussed how we'd want to proceed. The result is that because some of the applications are really huge code bases, often several KDE versions old (I think KMail contains code that has been introduced in KDE1 times and ported to new APIs ever since), we don't think it is likely that we could manage an all application port within one KDE release cycle, e.g. for KDE 4.3

A goal that we hope but can't guarantee to achieve is to have addressbook and calendar Akonadi native for 4.3
(Depending on the used features, some users might be able to use Mailody instead of KMail within the same time frame)

Of course any additional developers wanting to help speed things up are always welcome

Alec wrote:...and let me use different clients at the same stuff. I only use KDEPIM, so that does not really matter...

Actually this already matters even in this case, though it is not as crucial as when switching between different applications for the same task, because applications get better information about data changes than they would get from the traditional system.

However, the main advantage for usage scenarios like yours (local and remote storage locations) is the "proxy like" behavior which is one of Akonadi's design goals. I.e. since applications do not access the storage locations directly, they gain benefits such as caching.

Quite like a web proxy reduced both the amount of network traffic and reduced latency by caching web pages and sub content such as images, without the web browser having to deal with it any differently than getting the data from the actual source.

Alec wrote:In KDE 3, I'd have a little list of calendars, each with their own colors, with checkboxes next to them. I could of course do the same thing with KOrganizer4, but then I'm not using the Akonadi resource

This is still a valid setup and might be preferable to users until the applications can natively interact with Akonadi.
The mixed approach, i.e. using the Akonadi resource instead of traditional resources, is probably only suitable for "tinkerers".

Alec wrote:If I use it, they get all grouped under it, with the same color...

Each entry (so called "subresource") should still have its own color property and activation checkbox.
The Akonadi resource is basically behaving like a groupware resource here and they can have multiple "folders" as well, e.g. separate subresources for TODOs and Events.

Alec wrote:...and called something as useless as akonadi_ical_resource_14

Yes, sorry. An internal identifier getting leaked into the user interface.
Definitely needs to be fixed, though probably won't make it in time for 4.2.0

Alec wrote:I also had an impression that Akonadi had a large part about mail.

Akonadi can basically handle all kind of data types, but you are right that mail is probably the most important one.

Mailody's KDE4 based version is already designed to use Akonadi as its backend instead of handling the mail fetching and storing itself. Due to the complexity and amount of features of KMail it will take longest to port.

This delay is quite disappointing for us as well, but there is no point in doing a sloppy port just to deliver as early as possible.

As sad as it is, for most people it might be better to "skip" Akonadi for the moment.

Thank you for your interest!

Cheers,
_

Thanks a lot for clearing things up!

I guess I'll wait until Akonadi support matures, and in the mean time, I'll just use the old methods.

By the way, I really like the new KMail interface!