172
edits
Gaia/Contacts/Data Refactor/mozcontactsProposal: Difference between revisions
Jump to navigation
Jump to search
Gaia/Contacts/Data Refactor/mozcontactsProposal (view source)
Revision as of 16:09, 27 November 2014
, 27 November 2014no edit summary
No edit summary |
|||
| Line 43: | Line 43: | ||
* We can keep very easily the existing functionality of contacts merging, import from SIM, vCard, Facebook, etc. This proposal enables an easy migration path. | * 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 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. | |||