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:15, 27 November 2014
, 27 November 2014→Open Issues
| Line 48: | Line 48: | ||
* 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 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. | * 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. | * 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 = | = Conclusions = | ||
Avoiding a level of indirection introduces many advantages, makes our lives easier and at the same time eases the evolution. | Avoiding a level of indirection introduces many advantages, makes our lives easier and at the same time eases the evolution. | ||