Closed Bug 999288 Opened 11 years ago Closed 11 years ago

Figure out how can Gecko provide the *built-in* data store for messages?

Categories

(Firefox OS Graveyard :: General, defect)

ARM
Gonk (Firefox OS)
defect
Not set
normal

Tracking

(Not tracked)

RESOLVED INVALID

People

(Reporter: airpingu, Unassigned)

References

Details

This is a prerequisite on the Gecko side. Before Gaia starts using Data Store API to handle the conversation thread (bug 898364), Gecko needs to provide a central data store which manages all the messages including SMS and MMS.

One noticeable thing here is this kind of data store is not provided by any apps (through add() or put() in the Data Store API), it is a kind of *build-in* data store managed by the RIL or SIM, which means we have to figure out a formal data store name (e.g., "build-in-messages") that is predefined for the built-in messages data store, so that the messaging apps can know how to claim the access to that specific data store:

 {
   datastores-access: {
     "build-in-messages": {
       "access": "readonly",
       "description": ...
     }
   },
 }

This issue is similar to the contacts. We have to predefine "build-in-contacts" as a data store name to specify the data store used for the built-in contacts (compared to other kind of contacts like "facebook-contacts" which is managed by an external app for example).
s/build-in/built-in
A follow-up issue is: supposing the platform wants to provide multiple built-in messages data stores, where each of them is based on different SIMs. For example,

  "built-in-messages-sim-1"
  "built-in-messages-sim-2"

How can the app claim the data store name in its manifest without the knowledge about how many SIMs are installed in the device?
I thought we can have several datastores with the same name?
My proposal is: in order to distinguish the sources of data stores which share the same |name|, we can take use of the |owner|. Summarize my thoughts as below:

* For Facebook messages provided by the Facebook app 1, the attributes of DataStore will be:

    DataStore {
        name = "facebook-messages";
        owner = "app://facebook1.gaiamobile.org/manifest.webapp";
    }

* Similarly, For Facebook messages provided by the Facebook app 2, the attributes of DataStore will be:

    DataStore {
        name = "facebook-messages";
        owner = "app://facebook2.gaiamobile.org/manifest.webapp";
    }

Since the Facebook messages must be provided by third-party apps, the |owner| is supposed to be the app's manifest URL. When the web content calls |getDataStores("facebook-messages")|, the promise's resolver will return an array of 2 data stores in this example, where the |name| is the same (i.e., "facebook-messages") but the |owner| can be different. It's up to the caller to decide which data store it wants to sync up (could be both or just either one which is more reliable).

* For built-in SMS on SIM-1, the attributes of DataStore will be:

    DataStore {
        name = "built-in-sms";
        owner = "system-sim-1";
    }

* For built-in SMS on SIM-2, the attributes of DataStore will be:

    DataStore {
        name = "built-in-sms";
        owner = "system-sim-2";
    }

When the web content calls |getDataStores("built-in-sms")|, the promise's resolver will return an array of 2 data stores, where the |name| is the same (i.e., "built-in-sms") but the |owner| can be different. In this way, the messaging app only needs to claim the following manifest without knowing how many SIMs are actually installed in the device:

    {
        datastores-access: {
            "built-in-sms": {
                "access": "readwrite",
                "description": "access the built-in SMS data stores"
            }
        }
    }

Note that "built-in-sms", "system-sim-1", "system-sim-2"... have to be something formal defined in the Messaging API spec.

* For built-in MMS on SIM-1, the attributes of DataStore will be:

    DataStore {
        name = "built-in-mms";
        owner = "system-sim-1";
    }

* For built-in MMS on SIM-2, the attributes of DataStore will be:

    DataStore {
        name = "built-in-mms";
        owner = "system-sim-2";
    }

The same. The web content can call |getDataStores("built-in-mms")| to retrieve all the MMS data stores which are currently available in the device, as long as it claims the following manifest:

    {
        datastores-access: {
            "built-in-mms": {
                "access": "readwrite",
                "description": "access the built-in MMS data stores"
            }
        }
    }

where the "built-in-mms" has to be a keyword pre-defined in the Messaging API spec.
After more investigations, I realized in our current design we shouldn't distinguish the messages data stores by different |name|. In the above-mentioned cases, the |name|s of all the data stores should be the same (i.e. "messages").

Also, we shouldn't standardize the |owner| formats (but we may still expose that for the displaying purpose in the prompting dialogue so that users can know which apps to allow). Eventually, it's users' decision to allow the accessibility through the prompting dialogue (bug 942641), instead of being matched by developers' codes.

So, all the data stores will be:

* For Facebook messages provided by the Facebook app 1, the attributes of DataStore will be:

    DataStore {
        name = "messages";
        owner = "app://facebook1.gaiamobile.org/manifest.webapp";
    }

* For Facebook messages provided by the Facebook app 2, the attributes of DataStore will be:

    DataStore {
        name = "messages";
        owner = "app://facebook2.gaiamobile.org/manifest.webapp";
    }

* For built-in SMS on SIM-1, the attributes of DataStore will be:

    DataStore {
        name = "messages";
        owner = "system";
    }

  where each data record in this data store can have special properties:

    record.type = "sms";
    record.serviceId = 0;

* For built-in SMS on SIM-2, the attributes of DataStore will be:

    DataStore {
        name = "messages";
        owner = "system";
    }

  where each data record in this data store can have special properties:

    record.type = "sms";
    record.serviceId = 1;

* For built-in MMS on SIM-1, the attributes of DataStore will be:

    DataStore {
        name = "messages";
        owner = "system";
    }

  where each data record in this data store can have special properties:

    record.type = "mms";
    record.serviceId = 0;

* For built-in MMS on SIM-2, the attributes of DataStore will be:

    DataStore {
        name = "messages";
        owner = "system";
    }

  where each data record in this data store can have special properties:

    record.type = "mms";
    record.serviceId = 1;


Calling getDataStores("messages") will return all the above data stores to the user (totally 6 in this example). User has to determine which data stores can be accessed by the caller app through the prompting dialogue (bug 942641).

Is my understanding accurate?
It would be really great if we did not discuss in two places at the same time.  :-)  I posted my feedback to dev-webapi.
(In reply to Gene Lian [:gene] (needinfo? encouraged) from comment #5)
> 
> * For built-in SMS on SIM-1, the attributes of DataStore will be:
> 
>     DataStore {
>         name = "messages";
>         owner = "system";
>     }
> 
>   where each data record in this data store can have special properties:
> 
>     record.type = "sms";
>     record.serviceId = 0;
> 
> * For built-in SMS on SIM-2, the attributes of DataStore will be:
> 
>     DataStore {
>         name = "messages";
>         owner = "system";
>     }
> 
>   where each data record in this data store can have special properties:
> 
>     record.type = "sms";
>     record.serviceId = 1;
> 
> * For built-in MMS on SIM-1, the attributes of DataStore will be:
> 
>     DataStore {
>         name = "messages";
>         owner = "system";
>     }
> 
>   where each data record in this data store can have special properties:
> 
>     record.type = "mms";
>     record.serviceId = 0;
> 
> * For built-in MMS on SIM-2, the attributes of DataStore will be:
> 
>     DataStore {
>         name = "messages";
>         owner = "system";
>     }
> 
>   where each data record in this data store can have special properties:
> 
>     record.type = "mms";
>     record.serviceId = 1;
> 
> 

Hi Gene,

For SMS/MMS in SIM-1/SIM-2, May I know why we have to provide the service Id 
that the saved message comes from?
By my understanding, in current implementation, what we store is the iccid of 
the message instead of the serviceId. and we don't have to separate these
messages into different data store.
This is more flexible in UI presentation when device supports multi-SIMs.
Otherwise, things will go wrong when the user switches SIM-1, SIM-2, or 
inserts different SIM into the device.  :(
(In reply to Gene Lian [:gene] (needinfo? encouraged) from comment #5)
> After more investigations, I realized in our current design we shouldn't
> distinguish the messages data stores by different |name|. In the
> above-mentioned cases, the |name|s of all the data stores should be the same
> (i.e. "messages").
> 
> Also, we shouldn't standardize the |owner| formats (but we may still expose
> that for the displaying purpose in the prompting dialogue so that users can
> know which apps to allow). Eventually, it's users' decision to allow the
> accessibility through the prompting dialogue (bug 942641), instead of being
> matched by developers' codes.
> 
> So, all the data stores will be:
> 
> * For Facebook messages provided by the Facebook app 1, the attributes of
> DataStore will be:
> 
>     DataStore {
>         name = "messages";
>         owner = "app://facebook1.gaiamobile.org/manifest.webapp";
>     }
> 
> * For Facebook messages provided by the Facebook app 2, the attributes of
> DataStore will be:
> 
>     DataStore {
>         name = "messages";
>         owner = "app://facebook2.gaiamobile.org/manifest.webapp";
>     }
> 
> * For built-in SMS on SIM-1, the attributes of DataStore will be:
> 
>     DataStore {
>         name = "messages";
>         owner = "system";
>     }
> 
>   where each data record in this data store can have special properties:
> 
>     record.type = "sms";
>     record.serviceId = 0;
> 
> * For built-in SMS on SIM-2, the attributes of DataStore will be:
> 
>     DataStore {
>         name = "messages";
>         owner = "system";
>     }
> 
>   where each data record in this data store can have special properties:
> 
>     record.type = "sms";
>     record.serviceId = 1;
> 
> * For built-in MMS on SIM-1, the attributes of DataStore will be:
> 
>     DataStore {
>         name = "messages";
>         owner = "system";
>     }
> 
>   where each data record in this data store can have special properties:
> 
>     record.type = "mms";
>     record.serviceId = 0;
> 
> * For built-in MMS on SIM-2, the attributes of DataStore will be:
> 
>     DataStore {
>         name = "messages";
>         owner = "system";
>     }
> 
>   where each data record in this data store can have special properties:
> 
>     record.type = "mms";
>     record.serviceId = 1;
> 
> 
> Calling getDataStores("messages") will return all the above data stores to
> the user (totally 6 in this example). User has to determine which data
> stores can be accessed by the caller app through the prompting dialogue (bug
> 942641).
> 
> Is my understanding accurate?

Gene, from a conceptual point of view this proposal makes sense to me and is aligned with what we have been thinking for Contacts. 

From an architectural point of view, the current plan for Contacts is to introduce a hidden app that will be the owner of the contacts datastore. This will have the advantage of not polluting or making even fatter the system app which is currently so big. With messages I think we can have the same approach, what do you think?

thanks!
Please refer to the e-mail thread in the dev-webapi. We concluded we should let system app or other hidden apps be the owner of the data store, which means the owner will always be the manifest URL of an app. This will make the permission model of Data Store API more consistent.

Gecko shouldn't own the data store. Close this bug as INVALID.
Status: NEW → RESOLVED
Closed: 11 years ago
Resolution: --- → INVALID
Link to the topic at dev-webapi mentioned above:

https://groups.google.com/forum/#!topic/mozilla.dev.webapi/7fSvp7Dklwk
You need to log in before you can comment on or make changes to this bug.