Re: Next step for Data Store API?

Hello,

On Mon, Aug 4, 2014 at 5:33 AM, 송정기 <jungkee.song@samsung.com> wrote:
> Hi Gene, Marcos,
>
> Marcos wrote:
>> We want to drop DataStore - we don't want to standardize it. We ended up using named IDB stores in FxOS instead.
>> It just ended up duplicating IDB. I'll see if I can hunt down some notes outlining other problems. I believe Gene is also agreed (and knows more), so he might be able to provide a few more details.
>
> AFAIK, the Data Store API had been planned to support the data synchronization between applications that use other SysApps APIs such as Contacts Manager API, Web Telephony API, Messaging API, etc.

I agree that standardizing such API's would be premature at this
point. We need to experiment with implementations.

>
> Could you share any major decision points by which the named IDB replaced Data Store API in FxOS? And for SysApps APIs, do you want to leave it up to implementation specific decision now? Or do you still think there should be some new proposals to cover this data synchronization use cases between apps?

At least for now it is implementation specific. The use cases are
quite diverse and among others, the need for use-case specific
optimizations make standardization quite difficult. As implementations
mature, at a later stage we may look again for standardization
opportunities.
I have experimented in the past with separate sync and separate
storage interfaces, but indeed the overlap with e.g. IDB is
significant.
However, there are some ubiquitous data synchronization use cases
which we intend to support in web runtimes: the Bluetooth PhoneBook
Access Profile (PBAP) for Contacts and Call History, and Messaging
Access Profile (MAP) for SMS, MMS and email (for which there is
limited client support). We should perhaps start with these.

Even this will open up a series of questions. For instance, when the
user decides to connect with another device via Bluetooth, decision is
needed about keeping the data 1. transient (data is lost when the
devices are disconnected), 2. locally stored and synchronized, or 3.
locally cached. There are use cases which exclude one or the other
(e.g. 2, for flash wear, or 3, for limited memory). Then, during the
session it can be handled integrated or separately with other data
sources.

An implementation of a generic sync API (for 'people' data) needs to
take into account:
- heterogeneous data sources: local databases, SIM cards, external
devices, network services/accounts etc
- data retention policy: transient vs persistent/synced vs cached,
telling user preferences, which are matched to platform constraints
- latency and throughput requirements, optimization opportunities
(come from the use cases)
- possibly privacy policies and settings,
- delayed, inconsistent and duplicate data (likely delegated to the client)
- and a lot of other things.

This is quite complex, and exposing it to apps via API's is premature
and hardly sustainable. On option is hiding all of it, which is the
current intent, but no API.

If implementations can encapsulate most of this complexity, and the UX
use cases can be standardized, there we may have an opportunity.
One possibility for that minimal set would include:
- data source identification
- data policy preferences
- a sync method which is passed down to the user agent (may be
inferred from data source identity)
- a data iteration method.

But anyway, this is future work.

Best regards,
Zoltan

>
> --
> Jungkee Song
> Samsung Electronics

Received on Monday, 4 August 2014 08:13:22 UTC