[Kde-pim] (KDE)PIM abstraction layer on non-Gnu/Linux systems?

[Kevin Krammer]

Hi Friedrich,

On Saturday, 2013-10-26, 20:55:37, Friedrich W. H. Kossebau wrote:
> Hi Kevin,
> 
> Am Samstag, 19. Oktober 2013, 18:28:06 schrieb Kevin Krammer:

> > 2) As part of our Akonadi transition we've developed KResource plugins for
> > addressbook and calendar that use Akonadi as their storage location.
> > We call them Bridge plugins.
> > I think the one for addressbook works reasonably well, the one for
> > calendar
> > is a bit less well tested.
> 
> This integration might not necessarily have been done, would need the user
> to first do some work (and understanding what she/he is doing there), so
> the user will not automatically see the KResource data pool in the
> Akonadi-based programs, from what I understand.

We have an automated process for that but we currently don't trigger it yet.

I.e. the KResource migrator can not only migrate KResource backends to Akonadi 
resources (adding Akonadi resources for configured KResource backends), but 
can also setup the KResource plugins that access Akonadi.

I think we are currently only missing one or two Akonadi resource equivalents 
for KResource plugins though, i.e. the time to enable the second migration 
path might be soon.

> > > Or do the
> > > old resources create a different collective pool if accessed via the old
> > > API? So if I configure the event/contact Akonadi resources via
> > > KOrganizer
> > > and KAddressbook, will those (Akonadi-style?) resources still be listed
> > > and
> > > accessible via the old KResource API?
> > 
> > Yes, if the respective "akonadi" bridge plugin is configured.
> 
> I am tempted to interpret the "if" as "rather no" :P

Right, typically no. Can be easily done by the user, sysadmin or OSV though.

> > The main advantage of the Akonadi API is that it is asynchronous and that
> > the application only has to load data that it actually needs.
> > (the KResource system always loads all data of the given type and has its
> > share of problems with asynchronous backends, e.g. Akonadi)
> 
> Ah, right, that main advantage was already implicit in my head :)
> The other thing (share of problems) sounds like a recommendation to really
> move from KResource to Akonadi-storage API, okay.

It also depends on whether and when an application developer expects to go for 
a Qt5 port. The KResource API will almost certainly not be ported, requiring a 
change at that point.

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/20131026/b0ac21e5/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/