Closed Bug 1016838 Opened 10 years ago Closed 6 years ago

Provide a system-level datastore for local contacts

Categories

(Core Graveyard :: DOM: Contacts, defect)

Product:
Core Graveyard
Component:
DOM: Contacts
Platform:
ARM
Gonk (Firefox OS)
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

Status:
RESOLVED WONTFIX

People

(Reporter: jmcf, Unassigned)

Details

As per recent discussions on the Web API mailing list: 

Gecko will be exposing a datastore named 'contacts' (owned by the System App) that will allow certified apps (for the moment) to track what local contacts are on the device, and to copy
/ cache that data and index it according to their specific needs.

So in order to converge to this model it will be needed that Gecko exposes
this new datastore, and this is part of the remaining work that needs to
be done.

Consumer Apps will be able to read / subscribe to changes to that datastore. 

Writing operations to that datastore will be controlled by Gecko (API implementation).

Apps can continue using navigator.mozContacts API to read/write contacts, provided they have the proper permissions.
I definitely think we should do this. The main problem that we need to solve is how to provide the current "fuzzy phone number matching" logic that the contacts API currently supports. I don't want to build fuzzy phone number matching into the generic DataStore API, so we'll have to find another solution.

One option is to simply provide a "fuzzy phone number matching" function as a separate standalone function, separate from any database API. Then apps can build their own IDB database which allows fuzzy phone number searching.

Another option is to create a contacts API which is a subset of the current contacts API and *only* provides fuzzy phone number searching. It would do so by reading data from the DataStore API and return values from there. So the only data needed to be stored in the contacts API would be the mappings needed in order to do fuzzy phone number searching. All other data would just be stored in the "contacts" DataStore.
(In reply to Jonas Sicking (:sicking) from comment #1)

> One option is to simply provide a "fuzzy phone number matching" function as
> a separate standalone function, separate from any database API. Then apps
> can build their own IDB database which allows fuzzy phone number searching.
> 

We already have it in navigator.mozPhoneNumberService
Actually we need several things:

* fuzzy matching: this is actually already in mozPhoneNumberService. But it only does the matching part, in an asynchronous way: given 2 numbers in input, it can say whether they match.
* what we need is finding a contact _efficiently_ using either form of a number: national, international, local. In the Contacts API, we store the various forms of a number as indices, as well as their various substrings to offer a substring matching possibility.

That said, in the past, I know we used to use the "simple phone matcher" for this. I see it's still used in the Contacts app and in the Dialer, and I don't know why we switched from this for the Contacts API. Maybe Jonas you could shed a light on the requirements? Was the simple phone matcher yielding wrong results in some countries? Was it impossible to properly have IDB indices when using the simple matcher?
I don't remember why we added the fuzzy matching to the API. I think it was for performance reasons. Gregor or Reuben will probably remember.
(In reply to Julien Wajsberg [:julienw] (away until 2nd June) from comment #3)
> Actually we need several things:
> 
> * fuzzy matching: this is actually already in mozPhoneNumberService. But it
> only does the matching part, in an asynchronous way: given 2 numbers in
> input, it can say whether they match.
> * what we need is finding a contact _efficiently_ using either form of a
> number: national, international, local. In the Contacts API, we store the
> various forms of a number as indices, as well as their various substrings to
> offer a substring matching possibility.
> 
> That said, in the past, I know we used to use the "simple phone matcher" for
> this. I see it's still used in the Contacts app and in the Dialer, and I
> don't know why we switched from this for the Contacts API. Maybe Jonas you
> could shed a light on the requirements? Was the simple phone matcher
> yielding wrong results in some countries? Was it impossible to properly have
> IDB indices when using the simple matcher?

FWIW I proposed in bug 938265 to move Gaia's SimplePhoneMatcher to navigator.mozPhoneNumberService Gecko API implementation.
(In reply to Jonas Sicking (:sicking) from comment #1)

> Another option is to create a contacts API which is a subset of the current
> contacts API and *only* provides fuzzy phone number searching. It would do
> so by reading data from the DataStore API and return values from there. So
> the only data needed to be stored in the contacts API would be the mappings
> needed in order to do fuzzy phone number searching. All other data would
> just be stored in the "contacts" DataStore.

My understanding was that the current navigator.mozContacts.find will be kept as it is ... so in this case the find by tel number will be still working with all its niceties.
It almost feels like we're going down the service-oriented-architecture route here.  I think the SOA approach here would be to make a "fuzzy number search" app (ie service) which other apps would query via an activity.  The "fuzzy number search" app would consume datastores (services) as its input.

Probably overkill and not terribly efficient to use an activity with a full process spin-up, but just thought I would mention it as an idea.
Fuzzy phone number search is used when displaying the UI for an incoming phone call. We can't afford to launch additional processes before rendering that UI.
(In reply to Jonas Sicking (:sicking) from comment #8)
> Fuzzy phone number search is used when displaying the UI for an incoming
> phone call. We can't afford to launch additional processes before rendering
> that UI.

Yes, that's why we need APIs for this
DOM: Contacts isn't used anymore. 
Closing all remaining bugs.
Status: NEW → RESOLVED
Closed: 6 years ago
Resolution: --- → WONTFIX
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.