Confirm
360
edits
Changes
include very good explanation from Jonas
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.<br>
Enforce types of attributes (avoid to break other applications).
== Why not...? ==
=== Why not use specific APIs for the use-cases like the existing Contacts and SMS/MMS APIs? ===
Here's an [https://groups.google.com/d/msg/mozilla.dev.webapi/H2qobP0qzHM/o8PdD1CGvBEJ informative reply from Jonas Sicking on the dev-webapi list], included below:
The Contacts and MobileMessage APIs are richer in the sense that they
support things like richer querying, like filtering, sorting and
grouping.
However the Contacts and MobileMessage APIs has the severe shortcoming
is that you are forced to live with the limitations of what querying
capabilities those APIs have. Including the performance of those
quering API.
We are *constantly* having to revise these APIs because it turns out
that the querying capabilities aren't matching what our apps need.
This is not a workable long term situation. And it's not even a
workable short-term solution for 3rd party apps since we can't revise
the APIs to support the capabilities that every 3rd party app
developer needs.
This is why the DataStore API allows applications to synchronize data
into a application-local cache. This cache can be
stored/index/grouped/sorted in whatever format the application needs
in order to support its UI. It even allows things like merge data from
the MobilaMessage API and the Contacts API into a single location.
A very common reaction to this is "caching data in the application
means duplicating the data!". This is true, but the current path we're
on also causes a lot of duplication. Supporting all types of
filtering, sorting and grouping like we do, forces us to create a lot
of indexes. Indexes are effectively partial copies of the data. And we
have to create those indexes whether they are actually used or not,
because the API requires them.
By allowing applications to cache the data, only data that is actively
needed by installed application is copied. And we enable applications
to cache data in more formats than we could every think of and bake
into the API.
This obviously doesn't mean that DataStore API will solve all of our
problems. I suspect that something like the inter-app communication
API will still be needed.
=== Why not use the Inter App Communication API? ===
[[WebAPI/Inter App Communication]] has more complicated security issues and is being worked at a lower priority.
== Interface ==
