Elaborate more how the "readOnly" property works.

[airpingu]

For example, for a data store specified by the following label/name/owner values:

  label: "messaging",
  name: "messaging-sms"
  owner: "system"

The UA is the owner to save new messages into that data store. That is, whenever an SMS is received from the RIL, the UA will add one record into that data store (note that it dose NOT use the Data Store API like add(...) to do that). Similarly, whenever an SMS is sent out through the Messaging API, the UA will internally save that SMS into that data store. Again, it's not operated through the Data Store APIs.

In addition, this data store can still be modified by an app when the readOnly is exposed as FALSE to it, which means it can call add/update/remove/clear... to modify the data store. Otherwise, an app can only call get/sync to retrieve data.

In summary, the APIs will be exposed to an app with different capabilities:

1. If a data store is read only to an app, that app can use get/sync to retrieve data, but cannot use add/update/remove.
2. If a data store is NOT read only to an app, that app can use add/update/remove to modify data and get/sync to retrieve data.
3. If an app doesn't claim the datastores-access entry in its manifest, it won't have APIs to manage the data store because getDataStores(...) will return no data stores.

If an operation is not allowed, for example, put(...) will resolve the promise with the reject algorithm to notify the caller app if the data store is read only to that app.

[zolkis]

+1

[airpingu]

Will solve this by Tuesday and post the initiative version to the SysApps mailing list.

[airpingu]

Solved this at https://github.com/airpingu/data-store-api/commit/d57862228cf7dd3ab5076c14a82a1929245f6972