Confirmed users
360
edits
WebAPI/DataStore: Difference between revisions
include very good explanation from Jonas
(include very good explanation from Jonas) |
|||
| Line 12: | Line 12: | ||
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> | 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). | 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 == | == Interface == | ||