Akonadi Calendar

[David Narvaez]

On Thu, Oct 27, 2011 at 1:36 PM, John Layt <jlayt at kde.org> wrote:
> Hi,
>
> Sorry for not picking up your first email, I've been offline a lot lately.
> Seeing as I'm the one who wrote that README I should fill things in a bit
> more.
>
> The original author of the data engine had to copy the Akonadi interface from
> kdepim as it was not available in kdepimlibs at the time.  I moved it to the
> subfolder and updated it with some bug-fixes [1] as well as overhauling the
> data engine itself.  I'm supposed to be keeping the code in sync but forgot
> before the last release, so we need to look at refreshing the copy before the
> next release.
>
> The intention has always been to move the Akonadi calendar interface into
> kdepimlibs so everyone could use it, but I don't know if this has been done
> yet.  Once done we can delete the copy and switch the data engine to the
> kdepimlibs version.
>
> Sergio, do you know the status of this?
>
> It was at this point that I was suggesting we might move the code from the
> Calendar engine to the Akonadi data engine so the implementations and
> interfaces are consistent, but thinking about it again Akonadi is an
> implementation detail and a bad name for a high level api so perhaps separate
> data engines for Calendar, Mail, and Contacts are better even if they use the
> same underlying code and consistent api.

Well, you knocked me off :)

I think I understand the deal up to this point and I think this is the
migration I was asking about. What comes later is future thoughts on
how to expand the Calendar API, right? If so, I can try Aaron's
suggestion of cloning all kdepim, kdepimlibs and kde-workspace into a
migration mashup, see who gets killed and how, and ping back to the
relevant lists when it's ready for review.

My main concerns are putting the things where they belong (do they
belong anywhere in particular inside Akonadi? or is that yet to be
decided?) and also knowing in advance what other projects in KDE
depend on the Calendar API currently living in kdepim (as it will be
removed and will break those projects) but I guess I can address this
later issue in an e-mail at the general devel list.

Now, who should validate the migration plan and process? Someone at
KDE PIM, right? (I'm including the PIM list again to check on this.)
Thanks for the clarification.

> Currently the Calendar data engine is a one-way affair, it just fetches the
> existing events from Akonadi, you can't use it to add new events.  What I
> would like to see happen is a two-way integration using a Plasma service [2]
> for which I wrote the initial operations definition file [3] but stalled at
> that point.  The idea here is not to provide a full api or feature set, as
> creating events is rather complex and Akonadi/kdepimlibs provides advanced
> widgets for doing that which you don't want to be trying to replicate in
> Plasma as well.  I think an advanced PIM Plasma widget should link directly to
> and use the PIM widgets.  What the service would provide is api for adding
> simple events such as one-off reminders for plasmoids that want to integrate
> but are not really PIM specific.
>
> The other big thing that needs investigation is the abiltiy to configure what
> Akonadi resource to use, at the moment it just uses the default resource but I
> can imagine users might want to show different calendars in different widgets.
> Whether this is something to be provided through the data engine api or if
> it's something an applet should use akonadi directly for is a matter for
> debate.
>
> Basically, as far as I know, no futher work has been done on the Plasma end or
> the Akonadi end.  If you have any more questions, poke me with a stick and
> I'll get back to you when I can.
>
> Cheers!
>
> John.
>
> [1] https://projects.kde.org/projects/kde/kde-
> workspace/repository/revisions/master/show/plasma/generic/dataengines/calendar/akonadi
> [2] http://techbase.kde.org/Development/Tutorials/Plasma/Services
> [3] https://projects.kde.org/projects/kde/kde-
> workspace/repository/revisions/master/entry/plasma/generic/dataengines/calendar/calendar.operations

David E. Narvaez