Gene Lian (I already quit Mozilla) Reporter
	Description • 11 years ago

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.

	Julien Wajsberg [:julienw]
	Comment 1 • 11 years ago

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 ?

	Gene Lian (I already quit Mozilla) Reporter
	Comment 2 • 11 years ago

(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.

	Gene Lian (I already quit Mozilla) Reporter
	Comment 3 • 11 years ago

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.

	Gregor Wagner [:gwagner]
	Comment 4 • 11 years ago

(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.

	Jonas Sicking (:sicking) No longer reading bugmail consistently
	Comment 5 • 11 years ago

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.

	Jonas Sicking (:sicking) No longer reading bugmail consistently
	Comment 6 • 11 years ago

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.

	Oleg Zasypkin [:azasypkin]
	Comment 7 • 11 years ago

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....

	Gene Lian (I already quit Mozilla) Reporter
	Comment 8 • 10 years ago

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.

	Gene Lian (I already quit Mozilla) Reporter
	Comment 9 • 10 years ago

This bug will specifically be open for the step #2 at comment #8 (Gaia side).

	Julien Wajsberg [:julienw]
	Comment 10 • 9 years ago

Retitling this bug to make it closer to what we intend to do now.

	Julien Wajsberg [:julienw]
	Comment 12 • 8 years ago

Mass closing of Gaia::SMS bugs. End of an era :(

	Julien Wajsberg [:julienw]
	Comment 13 • 8 years ago

Mass closing of Gaia::SMS bugs. End of an era :(