Ask for precision about how works contact and calendar sync in sfos [answered]

asked 2017-01-19 12:10:30 +0300

cemoi71 gravatar image

updated 2017-01-20 12:15:33 +0300

Hello Sailors,

i would like to ask some questions to the dev-team, to understand better how exactly works the management of the contact and calendars.
Since a years i noticed some remarks that it's impossible internally to exchange some contacts between each type of accounts (google, activesync, carddav/caldav,memotoo,fruux, etc...), because of some rules.

I find the management a little bit confused, and give to some users the feelings that they are not really the owners of their contacts.
That is a little sensible theme because it felt that it don't go to the same way of the private sphere politic that claim jolla. I don't accuse jolla for any things, but the design of the interface seems to be confused.

  • First, on which system is based sfos natively? I guess caldav/carddav, but naturally i 'm not sure.
  • Then, which type of account are not able to exchange with an other? (e.g. seams that carddav/caldav is not able to exchange with google & activesync-exchange & memotoo)
  • Why the backup function make just a
    small backup of the sfos native
    account? and not one for all, or one for each accounts?
  • With the "share" function we may export all contact of all account in just one file per mail or mms or bluetooth, why it is not possible to use it for doing an exchange with the native system of sfos? so that the sfos have all, and is able to make a consistent backup and export.

Those questions are concretely formulated for a better understanding and are not in subject of joking or speculation. And i'll be thankful that answers are done from people who knows about it handles, and no speculation.
I someone have some other question about it for enlarging the acknowledgement on how it works, please do it, you're welcome.
But please stay on topic, not personally ask for example why did you do so and not so.
I just want to understand the interface and the philosophy as it is done know.

Have a good sails

edit retag flag offensive reopen delete

The question has been closed for the following reason "the question is answered, an answer was accepted" by cemoi71
close date 2018-05-03 13:48:55.101677




Some detailed information about this topic can be found at

Basically, SailfishOS uses a native SQlite3-based backend for the QtPIM API to store contacts. Unfortunately, it's based on what is now an old version of the QtPIM QtContacts API - and that version doesn't properly support separated addressbooks. This lack, combined with a UI decision which I will describe in more detail below, is a major cause of most of the issues with contact synchronisation, as contacts are currently separated in the backend via simple tags (in a field called QContactSyncTarget - a simple text field describing which account the contact came from), and heuristically aggregated together.

(The original design for the People application required that no intermediate prompts be required when creating a contact, and thus we couldn't explicitly ask the user which collection (i.e., account) the contact should be stored in. As a result, the backend has to be "clever" to determine which contacts from which sources are actually the same, and in determining which contacts to upsync where, when the contact is created on the device. Once we update our backend to properly support the separated collections in the new QtPIM QtContacts API, I will also ensure that we revisit this design choice...)

Currently, we don't sync any contact data from one online source with any other online source. This is because, originally, we had ToS requirements with one of the online providers, which prevented us from doing that at all. However, that online provider no longer supports contact synchronisation, so I suspect that this is no longer an issue (but I am not a lawyer...) Note that if you sync a contact from, say, CardDAV, and then modify it locally on the device, the local modifications will have "local device" ownership (and thus be eligible for upsync to other online services, not just the carddav server).

This also explains the behaviour of the backup function: it only backs up data which has "local device" ownership.

I don't understand your fourth point about the "share" function - it uses the same export method as the "backup" function, so the data should be identical.

Best regards, Chris.

chris.adams ( 2017-01-20 03:21:02 +0300 )edit

@chris.adams i'm glad that you see the thread and of your answer.
That's for me clear that you cannot really be up to date for this ToS Requrements.
But maybe you and your team may give some technical tipps for better experience, on giving the optimal links between these providers and these providers. And tells diplomatically that between this one and this one, may be complicated.

for example, seems to me that

  • exchange and webdav (caldav/carddav) are not share compatible because technically (bug or don't know what technical incompatibility), or ToS Requirement.
  • Google cal+contact not share compatible with webdav, technically or ToS Requirement.

For the 4th point, i was able to fill all my contact in the vcf with the share function, that the backup was not able to do this. I explain you the context.
In 2014 i had a google phone, calendar and contact in google account.
Then i bought the jolla phone, and bound it to this account.
In 2015/2016 i decided to go away from google, and make a try with memotoo and fruux (to test). And it worked with both: But i was not satisfied from the both solutions. i created maybe some contacts into it. Last year i decided to synchronise with cozy and their webdav (you know the story and the issues). And i was never able to synchronise my contact with cozy. My vcf in backup was really short. around 50 contacts, normally i had near of 400.

Shortly i was able to clean my contacts, and share i out through may, and import again in sfos. Did you saw it?
Now sync works fine between sfos and cozy for the contact. but seems that exchange active-sync is blind for it with sfos. And active-sync is able to sync calendars but cozy not...
Shortly told. backup function ,and share function don't make the same things. But maybe my case is maybe a special one.
Do you see what i mean now? Thanks a lot for answering, and have a good continuation.

cemoi71 ( 2017-01-20 11:18:25 +0300 )edit

I think most of the issues you describe are simply due to our current (lacking) backend support for separated addressbooks. Once we implement that properly, you will be able to choose precisely which addressbooks should be enabled for synchronisation elsewhere (and to which specific accounts).

Unfortunately until we do that, there's not much advice I can offer. The backups will only contain data which is tagged as "local" data (i.e., data which was added manually on the phone).

chris.adams ( 2017-02-01 03:43:34 +0300 )edit

@chris.adams thank you for your comment, which is quite interesting.
i had a feeling on this way but couldn't described it as you do. I find quite good that you feel where is the point of this issue.
Just a little question, for a short term, or transition.
Would it be possible and could help us having a kind of flags/tags by each contact which indicate in which account it has its entry? do you see what i mean?
Just for having (as user) an overview where (which account) is bound the contact (would include the sim card too). I would be interested on it until a the review that you've spoke about comes (seems to be planed for a far future).

cemoi71 ( 2017-02-01 11:36:59 +0300 )edit

You should be able to see that in the UI if you attempt to view the links for the contact (e.g., a linked contact will have various constituent contacts, each providing different data fields). But the UI won't say precisely which pieces of data come from which constituent, unfortunately - again, this is something that in the future will become much clearer once we have properly-separated addressbooks.

chris.adams ( 2017-02-13 04:06:10 +0300 )edit