Moving serializer plugins to respective akonadi-* repos?

[Daniel Vrátil]

On Tuesday, 6 March 2018 23:26:22 CET Sandro Knauß wrote:
> Hey,
> 
> > this came up today in discussion with Hannah and David who are trying to
> > get FatCRM working on Windows and they need the contact and calendar
> > serializers. However, we are not in the situation when we would be able to
> > build the entire kdepim-runtime on Windows, and FatCRM does not need
> > anything else from there anyway. Moving the serializers to the akonadi-*
> > repos would allow FatCRM (and potentially others non-KDEPIM Akonadi-based
> > projects, if there are any) to not depend on kdepim-runtime if they don't
> > need anything from there other than the serializers.
> > 
> > The disadvantage is that applications must runtime-depend on those
> > repositories even if they don't link against the libraries in them just to
> > make sure they have all the serializers installed. This is not a problem
> > for KDE PIM itself where everything depends on everything anyway, so we
> > may just need to document the requirement somewhere.
> > 
> > Actually, this might also be interesting in the terms of making Akonadi
> > better accessible to 3rd parties who may not be interested in any of the
> > crap from kdepim-runtime - Zanshin comes to mind here, as this move would
> > allow them to have a tiny flatpak image or even a Windows deployment
> > without dragging along stuff like POP3 resources and ITIP agents.
> > 
> > Opinions?
> 
> the first thought, okay that make sense and sounds logic, but without
> kdepim- runtime there are no resources so we end up with an empty Akonadi,
> with the ability to serialize data. So the next step would be, that we need
> to move the calendar/contact resources into akonadi*repos too, so we can
> feed Akonadi with data to serialize? Maybe we should see the bigger picture
> and think about how to restructure the repos, to make it easier for for 3rd
> party to use only the nessary stack of kdepim, before starting moving stuff
> around...

Ror usecase like FatCRM we don't need any resources. FatCRM has its own 
resource that feeds the data into Akonadi.

For cases like Zanshin, we would need only one (iCal for instance) to have a 
workable deployment, so maybe a very simplified build of kdepim-runtime would 
do here.

The main idea is to make Akonadi easier to use for projects that are not 
necessary interested in IMAP/POP3/CalDaV/Google/.... I would argue we can try 
to figure this out once the problem arises (or at the PIM sprint ;-))

Dan


> 
> hefee


-- 
Daniel Vrátil
www.dvratil.cz | dvratil at kde.org
IRC: dvratil on Freenode (#kde, #kontact, #akonadi, #fedora-kde)

GPG Key: 0x4D69557AECB13683
Fingerprint: 0ABD FA55 A4E6 BEA9 9A83 EA97 4D69 557A ECB1 3683
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kde-pim/attachments/20180307/c12f3684/attachment.sig>