Questions regarding code design choices for Akonadi resource

Shashwat Jolly shashwat.jolly at gmail.com
Mon Jun 29 12:03:58 BST 2020


Hey everyone!

As you may know, I'm working on a new resource for Akonadi that would
enable syncing EteSync contacts, calendar and tasks to Kontact. I have
implemented contacts/address books sync [0], and will now start working to
extend functionality to calendars and tasks. I have some questions to ask
before I start working on that. Here they are:

1. As this is a network backend resource, should *all* network calls be in
async KJobs?
Currently, I have two async jobs, each of which may have to fetch a lot of
data (retrieveCollections() and retrieveItems()). I understand that network
calls may take indefinite time to complete, and so async jobs make sense.
However, I have a lot of one-line network function calls in my code too
(Example: see [1]). Should I implement jobs for those too? I'm not able to
decide on the trade-off between a convoluted implementation (with jobs),
and the current in-line calls, which I'm not sure cause trouble or not.

2. Is there such a thing as too much abstraction? I sometimes have the
choice between making interfaces for function calls simple, but passing
extra information to functions vs only taking relevant parameters as input
to the functions. This is again a tradeoff between a simplified interface
and specificity. The extra information is passed by reference, otherwise
the choice would be easy. For example, I could make all job interfaces
simple by only passing a reference to the EteSyncClientState object, but it
has a lot of extra information and it hides the parameters the job actually
needs.

It would be great to have opinions on these queries.

[0]
https://invent.kde.org/sjolly/kdepim-runtime/-/tree/etesyncResource/resources/etesync
[1]
https://invent.kde.org/sjolly/kdepim-runtime/-/blob/etesyncResource/resources/etesync/etesyncresource.cpp#L181

Thanks
-- 
Shashwat Jolly
IRC: sjolly on Freenode
www.thejollyblog.tech
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kde-pim/attachments/20200629/112d8238/attachment.htm>


More information about the kde-pim mailing list