WebAPI/DataStore

Data Store API

This is the snapshot of a discussion between Mounir Lamouri, Thinker Lee, Gene Lian, Jonas Sicking and Hsin-Yi Tsai.
The work drafting happened on https://etherpad.mozilla.org/whatever-you-want

Use Cases

Allow an application to create data that can be shared with multiple other applications.
Allow multiple applications supply data to the same data store.
Support read-only stores like facebook contacts.
Support read/write stores like built-in contacts.
Support keeping a application-local cache of a data store. I.e. enable getting notified about changes to a data store so that the local cache can be kept up-to-date.
Enforce types of attributes (avoid to break other applications).

Interface

 interface DataStore {
   // Returns the label of the DataSource.
   readonly attribute DOMString name;
   // Returns the origin of the DataSource (e.g., 'facebook.com').
   // TODO: defines what the value should be if owned by 'system'.
   readonly attribute DOMString owner;
   // is readOnly a F(current_app, datastore) function? yes
   readonly attribute boolean readOnly;
   // TODO: id should be incremental.
   Future<Object>  get(int id);
   Future<void>    update(int id, Object obj);
   Future<int>     add(Object obj);
   Future<boolean> remove(int id);
   Future<void>    clear();
   readonly attribute DOMString revisionId;
   attribute EventHandler onchange;
   Future<DataStoreChanges> getChanges(DOMString revisionId);
   // TODO: getAll(), getLength().
 };
 
 interface DataStoreChanges {
   readonly attribute DOMString revisionId;
   readonly attribute int[] addedIds;
   readonly attribute int[] updatedIds;
   readonly attribute int[] removedIds;
 }

 partial interface Navigator {
   Future<DataStore[]> getDataStores(DOMString name);
 };

Manifest

For the application that provides the datastore

 {
   ...
   datastores-owned: {
     "contacts": {
       "readonly": true,
       "name": "Facebook contacts",
     }
   },
   ...
 }

For the application that wants to access the datastore

 {
   ...
   datastores-access: {
     "contacts": {
       "access": "readonly",
       "description": ...
     }
   },
   ...
 }

Incremental Schema

DataStore is designed for sharing data among applications. Applications will assume data types of attributes of objects in a data store. If the data type of an attributes is not consistent among applications, applications will be broken for read data from other applications with different assumption on the data type. That is why the data types of attributes should be enforced.

Every object in a data store is a tree. The path from root to any node can be represented as an ordered list of attribute names. Incremental schema is to define the type of an attribute while the path of the attribute was found first time. In an other word, once a new object was added to a data store, its tree of attributes will be traveled, and assigned the type of new attributes as the type of their values. A new attribute is one attribute whose path from root is never found before in a data store.

For example, if the following object is the object been added to a data store.

 {
   SN: 123,
   name: "John Lin",
   info: {
     address: ".....",
     birth: Date(....),
   }
 }

Then, the table of types of attributes should be

 SN: Integer
 name: String
 info: object
 info address: String
 info birth: Date

Then, the following object is added.

 {
   SN: 123,
   name: "John Lin",
   info: {
     address: ".....",
     birth: Date(....),
     phone: "123456",
   }
 }

The table of types of attributes should be

 SN: Integer
 name: String
 info: object
 info address: String
 info birth: Date
 info phone: String

Every time a new object was added to a data store, the types of attributes of the object would be checked against the types table of the data store. The action of adding will be failed if the type of any attribute does not match the type defined in the types table.

Issues

* {name, owner, value} is a complicated key.
* UI: what to do when we have multiple access requests?
* What's happening if the central gets changes during the process of local updates?
* |addedIds|, |removedIds| and |updatedIds| arrays should be synchronized. For example, the ID of record that has been updated and removed should only show up in the |removedIds| array. Need to define the behaviours.
* Should all data stores with the name share a schema?