Matěj Cepl Reporter
	Description • 11 years ago

(from thread http://thread.gmane.org/gmane.comp.mozilla.devel.gaia/7189)
Looking at https://developer.mozilla.org/en-US/docs/Web/API/MozMobileMessageManager 
I cannot wonder why is it allowed only for *certified* apps. I don't mind sending/receiving messages as such, but I do mind the rest. Why cannot I make a SMS 
Backup application to (re-)store all messages from the phone to/from the SD Card (getMessages/getThreads)?

Also, as it is noted in the thread, we would need some kind of addMessage method to add messages to the database directly.

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

Eventually we'll have a datastore instead of (or in addition to) this API, see bug 898364. Will make things easier I guess.

	(no longer active)
	Comment 2 • 11 years ago

Actually with bug 898364, is there anything else to do here?

	[:fabrice] Fabrice Desré
	Comment 3 • 11 years ago

(In reply to :Ehsan Akhgari (lagging on bugmail, needinfo? me!) from comment #2)
> Actually with bug 898364, is there anything else to do here?

Which app controls the schema used by this datastore? Can a 3rd party app reasonably use it?
Adding a storeMessage() API looks simpler to me overall.

	(no longer active)
	Comment 4 • 11 years ago

(In reply to comment #3)
> (In reply to :Ehsan Akhgari (lagging on bugmail, needinfo? me!) from comment
> #2)
> > Actually with bug 898364, is there anything else to do here?
> 
> Which app controls the schema used by this datastore?

The SMS backend, I would assume.

> Can a 3rd party app reasonably use it?

I do hope so!  That should be the point of that work.

> Adding a storeMessage() API looks simpler to me overall.

Well, the reason we have the data store API is to not have to design one API per storage use case like this.  :-)

	[:fabrice] Fabrice Desré
	Comment 5 • 11 years ago

So what happens if you want to restore your sms db? Do we need to run the sms app first to set up the datastore?

I think the point of datastore was to not need complex query & filtering apis - like the threading one in the sms case. But simple ones like get/add/remove would be provided to bootstrap datastores.

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

(In reply to Fabrice Desré [:fabrice] from comment #5)
> So what happens if you want to restore your sms db? Do we need to run the
> sms app first to set up the datastore?

What do you mean by "restore" here? Do you mean:

1. How we can we migrate our current SMS DB to a Data Store when starting to use Data Store API?

2. Or how can a third-party SMS app sync the data from the data store when it launches up?

I guess you're talking about the #1. I think we should let the system spp or other *hidden* apps (running on the parent process) to retrieve all the messages in the current SMS DB and save them back to a data store through the Data Store API.

That app will not only initialize that data store in the first place, but also be in charge of listening to the onreceived/onsent/... event handlers (via Messaging API) to add new coming messages to the data store.

> I think the point of datastore was to not need complex query & filtering
> apis - like the threading one in the sms case. But simple ones like
> get/add/remove would be provided to bootstrap datastores.

Yes, that's exactly the design of Data Store API. It still provides some basic methods like get/add/remove but doesn't provide advanced methods for constructing indexes or searching data.

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

Gene, please see the title of this bug :) The goal of this bug is to allow a 3rd party app to backup/restore messages.

	Vicamo Yang [:vicamo][:vyang]
	Comment 8 • 11 years ago

(In reply to Gene Lian [:gene] (needinfo? encouraged) from comment #6)
> (In reply to Fabrice Desré [:fabrice] from comment #5)
> > So what happens if you want to restore your sms db? Do we need to run the
> > sms app first to set up the datastore?
> 
> What do you mean by "restore" here? Do you mean:
> 
> 1. How we can we migrate our current SMS DB to a Data Store when starting to
> use Data Store API?
> 
> 2. Or how can a third-party SMS app sync the data from the data store when
> it launches up?
> 
> I guess you're talking about the #1. I think we should let the system spp or
> other *hidden* apps (running on the parent process) to retrieve all the
> messages in the current SMS DB and save them back to a data store through
> the Data Store API.

What about letting MobileMessageDatabaseService use DataStore API to insert/retrieve data?  It's still the thing we must do if we want to keep database related APIs.  I mean we create a 'mobilemessage' data store and sync it back to IndexedDB.  So Gaia can start working on Data Store tasks using this shared data store, and once they reach the milestone that Gecko SMS DB API is no longer relevant, we may go on to remove such duplicate. Note there are still conversation related APIs in W3C mobile messaging proposal.  MobileMessageDatabaseService == *hidden app* you mentioned.

> That app will not only initialize that data store in the first place, but
> also be in charge of listening to the onreceived/onsent/... event handlers
> (via Messaging API) to add new coming messages to the data store.

	Vicamo Yang [:vicamo][:vyang]
	Comment 9 • 11 years ago

(In reply to Julien Wajsberg [:julienw] from comment #7)
> Gene, please see the title of this bug :) The goal of this bug is to allow a
> 3rd party app to backup/restore messages.

For backup, it can be easily done by separating 'sms' permission to 'sms-read' and 'sms-write' (certainly not a good name).

For restore, I think that's a big problem especially when it involves our internal implementation.  And there is also a (broken) Android backend.  There are a lot technical details hidden from Gaia.  For example, bug 736708 implements Replace Short Message Type defined in 3GPP standard.  Such features need additional attributes come from raw SMS data that are not exposed in public mobile message APIs.  Will Gaia/backup app handle such hidden technical details?

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

(In reply to Julien Wajsberg [:julienw] from comment #7)
> Gene, please see the title of this bug :) The goal of this bug is to allow a
> 3rd party app to backup/restore messages.

Yeap, thank you for the reminder. I think once the messages can be managed by a data store, all we have to do is to release a "readwrite" data store permission to that 3rd party app for backing-up and restoring purposes.

	(no longer active)
	Comment 11 • 11 years ago

(In reply to comment #9)
> (In reply to Julien Wajsberg [:julienw] from comment #7)
> > Gene, please see the title of this bug :) The goal of this bug is to allow a
> > 3rd party app to backup/restore messages.
> 
> For backup, it can be easily done by separating 'sms' permission to 'sms-read'
> and 'sms-write' (certainly not a good name).
> 
> For restore, I think that's a big problem especially when it involves our
> internal implementation.  And there is also a (broken) Android backend.  There
> are a lot technical details hidden from Gaia.  For example, bug 736708
> implements Replace Short Message Type defined in 3GPP standard.  Such features
> need additional attributes come from raw SMS data that are not exposed in
> public mobile message APIs.  Will Gaia/backup app handle such hidden technical
> details?

I think those are technical challenges that we need to solve no matter what API we end up using.  And once we have a solution for those, it seems to me like an SMS restore app can just use the DataStore API to write new entries to the datastore, right?

	Kyle Machulis [:qdot] [:kmachulis] (INACTIVE)
	Comment 12 • 7 years ago

Cleaning up Device Interfaces component, and mass-marking old FxOS bugs as incomplete.

If any of these bugs are still valid, please let me know.