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

[Friedrich W. H. Kossebau]

Hi Kevin,

Am Samstag, 19. Oktober 2013, 18:28:06 schrieb Kevin Krammer:
> On Donnerstag, 2013-10-17, 22:57:05, Friedrich W. H. Kossebau wrote:
> > For the other part I still need a definite answer:
> > If code continues to use the old deprecated API and uses
> > KCal::CalendarResources and KABC::StdAddressBook::self(), will that code
> > have access to all the resources which are bound in via Akonadi?
> 
> Depends ;-)
> 
> There are two integration options:
> 
> 1) The KResource system is plugin based, each data type comes with at least
> a single file plugin (e.g. single vcard addressbook).
> If Akonadi, via a respective resource, is using the same storage, then they
> also share the same data.
> 
> 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.

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

> > So, will porting to the new API actually fix a problem in not being able
> > to
> > access the newer Akonadi resources? So bringing a value besides getting
> > rid
> > of all the deprecated warnings during the build?
> 
> 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.

Thanks
Friedrich
_______________________________________________
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/