Confirmed users
483
edits
(→Data flows: local and external modifications) |
|||
Line 95: | Line 95: | ||
Local contact addition or modifications needs to be done through the MozContacts API since Contact Provider's datastores are supposed to be readonly. | Local contact addition or modifications needs to be done through the MozContacts API since Contact Provider's datastores are supposed to be readonly. | ||
A Contact Consumer with access to the MozContacts API can add a new contact or modify an existing one via the MozContacts API, which will write the modification to the MozContacts internal indexedDB and the Local Contacts datastore. This datastore modification will trigger the datastore-change-* system message (and the DataStore.onchange event) which will wake the GCDS up. Once it is up, the GCDS will request a sync with the Local Contacts datastore to fetch the latest changes that will be recorded in the GCDS. This will also trigger a datastore-change-* notification and a DataStore.onchange event that will be received by the Contact Consumers observing this notifications. These Contact Consumers will need to sync with the GCDS to obtain the latest changes and query the appropriate Contact Provider where the changes were originated, in this case the Local Contact datastore. | A Contact Consumer with access to the MozContacts API can add a new contact or modify an existing one via the MozContacts API, which will write the modification to the MozContacts internal indexedDB and the Local Contacts datastore. This datastore modification will trigger the datastore-change-* system message (and the DataStore.onchange event) which will wake the GCDS up. Once it is up, the GCDS will request a sync with the Local Contacts datastore to fetch the latest changes that will be recorded in the GCDS. This will also trigger a datastore-change-* notification and a DataStore.onchange event that will be received by the Contact Consumers observing this notifications. These Contact Consumers will need to sync with the GCDS to obtain the latest changes and query the appropriate Contact Provider where the changes were originated, in this case the Local Contact datastore. The Contact Consumer responsible for this contact addition or modification can probably safely ignore the change notification, but that's an implementation detail that may defer between consumers. | ||
=== External contact addition or modification === | === External contact addition or modification === | ||
[[File:Contactprovideraddmod.png|800px|x600px]] | [[File:Contactprovideraddmod.png|800px|x600px]] | ||
The flow in this case is pretty similar to the previous one with the difference that the contact change is not done through the MozContacts API but instead it is done through the specific mechanism the Contact Provider has for modifications of the contact data they own. This could be an app specific UI, a synchronization with an external service, etc. | The flow in this case is pretty similar to the previous one with the difference that the contact change is not done through the MozContacts API but instead it is done through the specific mechanism the Contact Provider has for modifications of the contact data they own. This could be an app specific UI, a synchronization with an external service, etc. In any case, an addition or modification of a contact stored in a Contact Provider datastore registered with the GCDS will trigger a notification that will wake the GCDS app up which will sync with the provider's store and trigger a new notification that should be received by Contact Consumers just like in the previous flow. | ||
=== Contact | === Contact Consumer search === | ||
Each Contact Consumer should keep a local indexedDB with the appropriate indexes to fulfill its specific search requirements. So contacts searches will be done by querying Contact Consumer's local indexedDBs. | |||
=== Contact Provider installation === | === Contact Provider installation/uninstallation === | ||
When a new application exposing a datastore named 'contacts' is installed or uninstalled an datastore-change-contacts system message should be triggered and should wake the GCDS up as mentioned [[Gaia/Contacts/Data_Refactor#Notification_mechanism_about_datastore_changes_.28aka_DataStore_onchange_scheduler.29]]. Once it is up, the GCDS should fetch the contact information from the new Contact Provider and populate its datastore with the corresponding information. This population will trigger a change notification that will be received by Contact Consumers which should update their local indexedDBs with the new added information. | |||
== Platform requirements == | == Platform requirements == |