Preface

With regard to the Contacts Data Architecture for Firefox OS, this page describes a refinement of the initial architecture proposed at https://wiki.mozilla.org/index.php?title=Gaia/Contacts/Data_Refactor/ . It is strongly recommended to read the former page in order to understand the context and implications.

Introduction

This proposal advocates for collapsing two datastores (mozContacts and GCDS) into one. As a result the role of the GlobalContactsDatastore will be played by the regular mozContacts datastore. An entry in the referred datastore could have local data and/or pointers to contacts present in the external providers datastores (Facebook, Gmail, etc.). We will be providing a library that will allow to obtain all the data associated to a mozContact entry (MultiContact library).

To support this approach the mozContact object will be extended with a 'sources' attribute (vcard standard) intended to contain an array of tuples (external service provider, id of the external contact referred to its origin datastore). There can be contacts in the system that may only exist in the external service and in that case all the mozContact attributes will be empty, apart from the referred 'sources' attribute. On the other hand there could be local contacts that only contain data present on the device and which 'sources' attribute will be empty.

Architecture

The figure above depitcs the proposed architecture. The main components are:

• Contacts Providers and their Datastores. They will create, update or delete contacts data in their specific datastores. It is expected that Contact Providers will be as well in charge of bidirectional synchronization with external contact providers (Facebook, Gmail, etc.).

• Contacts Manager. It will responsible for listening to changes in the providers datastores and synchronizing with the GlobalContactsDatastore accordingly. It performs the matching and merging algorithms for those contacts arriving from the provider datastores.

• Contact Index Datastore. It is a datastore that will contain an index (by tel, email, name) to the Global Contacts Datastore. Any certified app in the system can get access to this index, including the Contacts App and the Contacts Manager. The main role of this datastore is to share a common index between all certified apps. However, if any app needs an specific index it will have to create it by itself, by means of using the sync facilities provided by the global datastore.

• Contacts App. The Contacts App as we know it, but with no specific dependencies on Facebook. The Contacts App can perform active matching and merging by getting access to the Contact Index Datastore. However it is expected that Contacts App will also keep its own indexes to support the search requirements from the Contacts UI.

• Consumer App. Any certified app in the system that wants to get access to contacts (dialer, messaging, email, etc.)

• Other apps. If granted, privileged apps may get access to the Global Contacts Datastore or any other external service datastore. The mozContacts find method could still be used but only to get access to local contacts and not to contacts which belong to external providers.

Sequence Diagrams

The figure below illustrates three use cases of the referred architecture. Firstly the arrival of a new contact coming from an external provider. Secondly, the addition of a new contact from the contacts app, and finally how the contacts application can get access to contact data from the different sources.

Advantages

• We keep mozContacts as the Contacts authority in the system. If there is a Contact known to the system then it will be present on the mozContacts store. As a result any app will be able to get access to it, although they might not to be able to get access to all of the data, as the datastores themselves will impose access levels restrictions.

• Whenever a change is made locally it is automatically propagated and we will not need to wait for the propagation of changes between the different datastores and indexedDBs.

• We can keep very easily the existing functionality of contacts merging, import from SIM, vCard, Facebook, etc. This proposal enables an easy migration path.

Open Issues

• What about the promised contacts unmerge functionality? If we only allow to unmerge manually made mergers (active mergers), then that is a functionality to be implemented by the contacts app itself, so there is nothing to worry about at infrastructure level.

• What happens to the mozContacts API and the find function? mozContacts API will still be present as API functions are to be needed in order to keep the consistency of the mozContacts store (save method). The find method will be kept as well but applications will be given the hint that only the local contacts information will be indexed by the implementation.

• Shouldn't all this infrastructure be implemented by Gecko? This is still an open question but the main issue that have led us to think on the datastores is that keeping a huge index in a central database might a burden. As a result, this distributed infrastructure at the Gaia side with the support of datastores at the Gecko side can be a good balance between platform level and application level.

Conclusions

Avoiding a level of indirection introduces many advantages, makes our lives easier and at the same time eases the evolution.