Closed Bug 898364 (sms-db-in-gaia) Opened 7 years ago Closed 3 years ago

[Messages] Implement a Database inside Gaia to hold messages and threads information

Categories

(Firefox OS Graveyard :: Gaia::SMS, defect)

ARM
Gonk (Firefox OS)
defect
Not set

Tracking

(Not tracked)

RESOLVED WONTFIX

People

(Reporter: airpingu, Unassigned)

References

Details

(Whiteboard: [sms-most-wanted])

User Story

Migrate the Messaging APIs to the DataStore APIs.

Attachments

(1 file, 1 obsolete file)

This is a super big work since we've already had a quite complicated database dealing with conversion threads in Gecko. Moving it to Gaia could be painful but we definitely start planning how to work on it.
Gene, do you know how a datastore-based api will look like for SMS ? The plan is to have only one datastore for SMS, and handle everything in gaia ?

My concern is (still) about the number normalization/matching stuff... Does that mean we'll need phonenumberutils in Gaia, or will the fuzzy matcher (as implemented in bug 883923) be enough ?
(In reply to Julien Wajsberg [:julienw] (PTO 15th -> 28th July) from comment #1)
> Gene, do you know how a datastore-based api will look like for SMS ? The
> plan is to have only one datastore for SMS, and handle everything in gaia ?

Data Store API is still on going at bug 871445.

Basically, Gecko will still be in charge of handling the main message database. With Data Store API, Gecko can notify the registered Gaia apps what's being changed dynamically in the message database (e.x., when message is added, deleted or modified).

In this way, Gaia can update its thread database based on the dynamic changes. For example, whenever a message is added in the Gecko's database, the Gaia can get a notification about that change, thus adding that message ID into its corresponding thread.

> 
> My concern is (still) about the number normalization/matching stuff... Does
> that mean we'll need phonenumberutils in Gaia, or will the fuzzy matcher (as
> implemented in bug 883923) be enough ?

Indeed, we use quite a lot PhoneNumberUtils functions in Gecko. It's another big issue of how to let Gaia be able to utilize PhoneNumberUtils as well. I used to hear Gaia doesn't like to import PhoneNumberUtils since it's too big to load and would occupy quite a lot memory for each content process.

Maybe, we have to export PhoneNumberUtils APIs to Gaia.
Please see comment #2.

Do you think it's worth exposing PhoneNumberUtils APIs to Gaia?

Another alternative is we can let System App load PhoneNumberUtils and other apps can use Inter-App Communication or Activities APIs to interact with it. However, we'd still have two memory copies in the System App and the Gecko, which sounds a bit resource-wasting.
Flags: needinfo?(mounir)
Flags: needinfo?(jonas)
Flags: needinfo?(mounir) → needinfo?(anygregor)
(In reply to Gene Lian [:gene] from comment #3)
> Please see comment #2.
> 
> Do you think it's worth exposing PhoneNumberUtils APIs to Gaia?
> 
> Another alternative is we can let System App load PhoneNumberUtils and other
> apps can use Inter-App Communication or Activities APIs to interact with it.
> However, we'd still have two memory copies in the System App and the Gecko,
> which sounds a bit resource-wasting.

We shouldn't load it twice especially in gecko and in the system app where we can't unload it. If needed, the system app should just access the gecko version of PhoneNumberUtils.
Flags: needinfo?(anygregor)
I think exposing PhoneNumberUtils.js as a certified API would make sense. We might want to expose it to more apps later, but lets start with certified for now.
Flags: needinfo?(jonas)
I should also add that I don't think there is any hurry to do this. If what we currently have is working fine, then I think we should stick with it for now.

I will be pushing for the standardized API to use a model where the application does it's own threading by using the DataStore API. Once we want to switch to using a standardized API, then we'll need to solve this bug.

But there are lots of unanswered questions and so it's unlikely that the standard will be finalized very soon.

But if we want to give the messaging app more flexibility already today in how it displays threads, then I think fixing this bug is the way to go. But I don't know if we have any such issues right now.
Depends on: 903431
Summary: Moving conversation thread database from Gecko to Gaia → Moving conversation thread database from Gecko to Gaia by introducing DataStore API
Depends on: 999288
Attached file GitHub pull request URL (draft) (obsolete) —
Added URL to very early draft version for feedback and discussion purpose. Currently it's a mix of datastore and mozMobileMessage to make integration\testing easier. Working on it constantly to figure out:

* what API method we need;
* what indices we should build for fast retrieval;
* what data fields we need to store in datastore;
* what filters\paging\sorting we should support;
* and etc....
We just had a F2F discussion about this in the Taipei's COMM work week. Currently Gecko maintains two kinds of IndexedDBs: "messages" and "threads-related" DBs. Our final goal is to move the "threads-related" ones to the Gaia's Messaging App. To keep the backward compatibility at any time points, the road map is:

1. (Gecko) Migrate the "messages" IndexedDB to the "messages" DataStore internally, but still keep the "threads-related" IndexedDBs to ensure the Messaging API can still work with the threads (e.g., the getThreads() or getMessages() methods).

2. (Gaia) The Messaging App is now able to use the DataStore APIs to manage the "messages" DataStore through the add()/remove()/sync()/onchange... functions. At this point, the Messaging App can now create its own threading/searching IndexedDBs by the sync with the DataStore. Then, it can stop using the Messaging APIs to query threads/messages.

3. (Gecko) Remove the "threads-related" IndexedDBs from Gecko since the Messaging App will no longer use Messaging APIs to manage threads or search messages. Then we can remove the "threads-related" and "search-related" Messaging APIs. Eventually, only partial Messaging APIs related to the messaging-specific purposes will be kept, including send()/sendMMS()/retrieveMMS()... etc.

I'll post this plan on the dev-webapi mailing list and fire bugs accordingly.
Depends on: 1020189
Blocks: 1020198
This bug will specifically be open for the step #2 at comment #8 (Gaia side).
User Story: (updated)
Retitling this bug to make it closer to what we intend to do now.
Blocks: messages-nga
Summary: Moving conversation thread database from Gecko to Gaia by introducing DataStore API → [Messages] Implement a Database inside Gaia to hold messages and threads information
Attachment #8417014 - Attachment is obsolete: true
Alias: sms-db-in-gaia
Whiteboard: [sms-most-wanted]
Mass closing of Gaia::SMS bugs. End of an era :(
Status: NEW → RESOLVED
Closed: 3 years ago
Resolution: --- → WONTFIX
Mass closing of Gaia::SMS bugs. End of an era :(
You need to log in before you can comment on or make changes to this bug.