MozillaWiki

WebAPI/DataStore: Difference between revisions

Page Discussion

WebAPI/DataStore (view source)

Revision as of 13:44, 23 August 2013

1,305 bytes removed ,  23 August 2013
no edit summary
No edit summary
Line 11: Line 11:
Support read/write stores like built-in contacts.<br>
Support read/write stores like built-in contacts.<br>
Support keeping an 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.<br>
Support keeping an 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.<br>
Enforce types of attributes (avoid to break other applications).


== Why not...? ==
== Why not...? ==
Line 64: Line 63:
== Interface ==
== Interface ==


   interface DataStore {
   interface DataStore : EventTarget {
     // Returns the label of the DataSource.
     // Returns the label of the DataSource.
     readonly attribute DOMString name;
     readonly attribute DOMString name;
Line 84: Line 83:
      
      
     attribute EventHandler onchange;
     attribute EventHandler onchange;
     Future<DataStoreChanges> getChanges(DOMString revisionId);
     Promise<DataStoreChanges> getChanges(DOMString revisionId);
      
      
     // TODO: getAll(), getLength().
     // TODO: getAll(), getLength().
Line 126: Line 125:
   }
   }


== Incremental Schema ==
== Revisions and changes ==
DataStore is designed for sharing data among applications.  Applications will make some assumptions on data types of attributes.  If the data type of an attributes is not consistent among applications, applications may be broken.  So, data types of attributes should be enforced.
to define types of an attributes while attributes with a new path were found first time.  In another word, once a new object was added to a data store, its tree of attributes will be traveled, and define the type of new found attributes with the type of their values.


For example, if the following object is the object been added to a data store.
The revisionId is a UUID and it can be used to retrieve the delta between a particular revisionId and the current one. This operation is done using |Promise<DataStoreChanges> getChanges(DOMString revisionId);|. Note that the object DataStoreChanges contains only useful operations: for example, the ID of record that has been updated and removed only shows up in the |removedIds| array.
 
  {
    SN: 123,
    name: "John Lin",
    info: {
      address: ".....",
      birth: Date(....),
    }
  }
 
Then, the types table of the data store is
  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 types table 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 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 ==
== Issues ==
Line 173: Line 133:
  * UI: what to do when we have multiple access requests?
  * UI: what to do when we have multiple access requests?
  * What's happening if the central gets changes during the process of local updates?
  * 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 same name share a schema?
  * Should all data stores with the same name share a schema?
  * Enforcing types can be a footgun. What should a data provider do if it decides some key should have a different type?
  * Enforcing types can be a footgun. What should a data provider do if it decides some key should have a different type?
Baku
Confirmed users
53

edits

Retrieved from "https://wiki.allizom.org/Special:MobileDiff/698576"