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

Sat Oct 19 17:28:06 BST 2013

Hi Friedrich,

On Donnerstag, 2013-10-17, 22:57:05, Friedrich W. H. Kossebau wrote:
> Hi Andras & Kevin,
> 
> thanks for your detailed answers.
> 
> Am Donnerstag, 17. Oktober 2013, 10:01:20 schrieb Kevin Krammer:
> > Am Mittwoch, 2013-10-16, 22:21:17 schrieb Friedrich W. H. Kossebau:

> > > The last patch/MR had the term "Akonadi" in it a few times, which raised
> > > eyebrows, as some programs of the project are also (successfully)
> > > targetting non-Gnu/Linux platforms (Windows/OSX/Android/GNOME/Unity) and
> > > "Akonadi" is for some reason connotated with bloat & big dependencies
> > > ("that needs then also a database system and D-Bus? and lots of
> > > processes, eating memory for breakfast?").
> > 
> > Basically all PIM solutions use a database, even a lot of
> > "just-mail-clients", browsers and other applications do.
> > The main problem with D-Bus seems to be that other platforms seem to be
> > very restrictive of overly complicated when it comes to services.
> > Shouldn't be a problem on OSX, GNOME or Unity though.
> 
> Windows (sadly) is important for the programs in case.

My understanding is that D-Bus can't just be started as a session service for 
whatever reason but application's have to start it themselves.
It is ported to Windows though.

> > > I tried to reason that these days using KDEPIM means Akonadi anyway (at
> > > least installed), disregard of using the old deprecated API or the new
> > > Akonadi one, so the patch would not change the existing dependencies (is
> > > that actually true? :) ), just result in modern use of KDEPIM, so
> > > perhaps
> > > that patch can still go in.
> > 
> > Yes, actually true, to a certain extent :)
> > One could use the KResource APIs stand-alone when restricting oneselves to
> > single file storage, e.g. all entries of an addressbook in a single vCard
> > file. No mail access obviously, no groupware access or similar.
> 
> And most important no integration still with any possible platform PIM
> system, so no real advantage. Need would be to feed/fetch data to the
> existing data pools, not create an own data pool.

Right, good point.

> > And putting onself in the situation of staying with Qt4 technology of
> > course, KResource is unlikely to be ported to Qt5.
> 
> He, Qt5 needs porting? ;)

Lets say KResources has been deprecated long ago and won't transit into a 
Frameworks 5 world :)

> > I think Windows has something conceptually but without any local backends,
> > basically just an API to access Exchange if the system is configured for
> > exchange.
> 
> Okay. Possibly any possible simple system connection plugins would then just
> target one dedicated system, like Mozilla DBs. Better than nothing.

I am not sure if Mozilla has any out-of-process integration points at all.

> > > Q5: What else would you recommend to developers who want to provide
> > > their
> > > KDE programs as stand-alone packages on those system and have some
> > > read/write access to the system's PIM data?
> > 
> > Use the KDE PIM data classes, e.g. KCalCore types, KABC::Addressee, KMime,
> > and develop your data access layer restricted to your specific needs.
> 
> So KCalCore types, KABC::Addressee, KMime are usable independently of the
> current storage interfacing system, i.e. Akonadi? Very good.

Yes. Akonadi specific extensions for each data type are in different libraries 
(in the repository in subdirectories of the kdepimlibs/akonadi directory).

> Because seems I am looking for something that is the "Phonon" API of PIM.
> A simple API for the most typical simple usecases (picking an event/contact
> from existing ones, creating a new event/contact, picking a message, sending
> a message etc).

The Akonadi client API, especially with its higher level components such as 
models and widgets, would qualify for that somewhat. It's just that there is 
only one "backend" of that API: Akonadi Server.

> No built-in caching mechanism in that layer. The backend may do that, very
> fine and lots of reason to do so, but that should only start behind the
> respective plugin to the abstraction layer, not already before (looking from
> API user side).

Akonadi does that. Client side classes like the EntityTreeModel do a bit of 
caching as well though.

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

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

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

Cheers,
Kevin

http://techbase.kde.org/Development/AkonadiPorting/AddressBook

-- 
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/20131019/5918f319/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/