[Ubports-dev] Plans for contact synchronization via CardDav

Alberto Mardegan mardy at users.sourceforge.net
Wed Mar 7 10:25:40 EST 2018


Hi all!
  I'd like to share some information on what I've been working on in
part of my spare time, on the topic of enabling contact synchronization
with Nextcloud and possibly other contact providers.


THE CURRENT SITUATION
=====================

I've been in touch with Renato, who in Canonical was the main developer
for the Contacts and Calendar applications, and I got to understand a
bit of the architecture.

Contact synchronization is managed by Buteo [1], which was developed by
Nokia and is also used by Jolla in their Sailfish OS. This is a
plugin-based system; we already have a plugin for synchronizing google
contacts, and we "simply" need a plugin for CardDav (the protocol used
by Nextcloud and others).

Unfortunately, the Buteo protocol does not specify where contacts should
be saved. So, while Jolla has implemented a QtContacts backend based on
sqlite [3], Canonical opted to write a D-Bus service,
address-book-service [4], which in turn talks to EDS
(evolution-data-server) to actually store the contacts there.
The result of this is that I've managed to build Jolla CardDav plugin
for ubports, and managed to successfully download my contacts from
nextcloud, but the address book application won't see them: they have
been written to an sqlite database which no application currently is
reading, instead of ending up into EDS, where the address book app
expects them to be.


THE PROPOSED SOLUTION
=====================

My opinion is that the Canonical solution was overengineered: while the
idea of reusing some open source component like EDS brings some gains in
term of sharing the contacts with the rest of the system, wrapping it in
yet another API (the address-book-service) only adds more maintenance
burden for us.

While we could write a QtContacts backend which would store the contacts
into EDS, that's a lot of work (which I don't have time to do) and
besides there's no guarantee that Jolla would converge on our solution.
And I really think that we should try as much as possible to share our
contacts architecture with Jolla, to minimize our efforts.

So, I would propose to drop the address-book-service as well as the EDS
contacts components: this has the added benefit of freeing up a bit of
RAM, as these services are persistently running even when unneeded.
Instead, we would use the same solution adopted by Jolla: a simple
sqlite backend.

Now, I'm fully aware that dropping EDS contacts takes away the
possibility of sharing contacts with those desktop applications using
EDS as backend (mostly GNOME ones), but this is a sad outcome of us
having little manpower. Once the situation changes, we can always come
back to this decision and implement a direct EDS backend for QtContacts,
but for the time being I don't have the time to do that.

Note that nothing changes for our application developers: the way to
share contacts is still via the Content Hub, which is backend-agnostic;
they will not have direct access to the sqlite database, so your
contacts are safe from malicious apps anyway.


ROADMAP
=======

I've already submitted a few changes to the merproject (Jolla's) gitlab
to have their components build successfully on Ubuntu, and they happily
accepted them.
I've also worked on the QtContacts upstream project (QtPim), to reduce
the patch delta we had in Ubuntu. That's a big amount of work, still
ongoing, but if I'm not mistaken the parts which we strictly need for
our contacts implementation have already been accepted.

So, the current to-do list, to the best of my knowledge, is:

- update address-book-app to use the latest QtContacts, and remove the
bits specific to address-book-service/EDS;

- integrate Jolla's CardDav plugin into ubports

- integrate Jolla's Google contacts plugin into ubports

- remove our Google contacts plugin

- remove address-book-service, remove/disable the EDS bits related to
contacts (we are still using EDS for calendar)

- Provide a migration path, so that the user's existing contacts get
migrated to the new sqlite DB when upgrading


None of the above is really trivial, but I believe that this is the way
which can get us to the result with the minimum effort while providing a
long-term strategy to reuse more of Jolla's open source products (for
instance, they have also a Buteo plugin which fetches contacts from the
VK social network).

I'll keep you updated as I progress, but please don't expect any of this
to happen soon, as I've got my hands in many projects and the free time
is always less and less. :-)


Ciao,
  Alberto


[1] https://github.com/ubports/buteo-syncfw
[2] https://git.merproject.org/mer-core/buteo-syncfw
[3] https://git.merproject.org/mer-core/qtcontacts-sqlite
[4] https://github.com/ubports/address-book-service



More information about the Ubports-dev mailing list