Re: Introducing the DataStore API

Top posting since it has started that way.
I think I have talked enough on the F2F about this, but it seems the
current version looks pretty good:
https://etherpad.mozilla.org/whatever-you-want
We just need to define what values would be supported for the 'owner'
property (+ see how can we track data source), and specify (at least
in words) how to link with querying interfaces.

Also, we need to update the use cases. So far we have:
- 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)

I would add:
- Support multiple stores of the same type (e.g. multiple contact
addressbooks), for privacy and security considerations. This actually
reduces to:
- support tracking store data source information; source is also
important when dealing with account-specific information which has
been aggregated into store-specific structures based on multiple
stores, such as Person concept in Contacts; when the user removes (not
only disables) an account, (s)he would like all account-specific data
go away and not have any residual copies luring in the system. Data
stores really need to be physically separated based on source, so we
need to have 'source' being part of this interface.

- support for fine-grained user control on which apps can access which
stores (read/write)

- support for avoiding physical copying/duplication of the data (also
solving the Gallery issue): is this an implementation issue?

- support 2 modes: when data is synchronized into the runtime
(imported from native/system side), and when data is imported from
runtime storage into app-specific storages. Currently the same API
supports both, the implementations would make the difference

- add support for creating basic application-specific indexes and for
basic query/filtering mechanism (covering 80% of use cases). Domains
would need to enter requirements here, i.e. Contacts, Messaging,
Telephony. This could be done by a related, but separate interface. In
that case making the link to given DataStore's needs to be formalized
in the API spec.

For Telephony (call history) it is the simplest: reverse index by
start time, index by remote party, index by subscriber identity
(SIM/account), label.

For Messaging: index by time, from, to (cc, bcc), subscriber identity,
messaging type (SMS, MMS), label.
Conversation support is to be defined by the app, and it is
transparent to this interface. Most messaging data models today are
based on conversations, but based on the discussion on the Madrid F2F
with Jonas, this can get too divergent to be standardized now.
However, we agreed with Eduardo that we may aim to include a simple
interface which would support >80% of the use cases, i.e. querying for
conversation view with one or more recipients ('to/cc/bcc'
corresponding to 'from'). The rest would be covered by the simple
queries from above.

For Contacts: by name, company, label, ... (other simple properties).

Supporting labels would give an opportunity to implement creative
features which require multiple stores of different type, but this is
not part of this interface spec.

I have played with similar ideas in my Messaging proposals from last
autumn, and the way I would do it now:
- have a DataSource interface (almost?) identical to this DataStore,
- add a data filtering interface implementing the simple use cases
from above (IndexedDB a good candidate, but I used a simplified one)
- add a DataStore interface which links together a data filtering
interface with one or more DataSource interfaces. This DataStore could
be used then in Contacts, Messaging, Telephony, and may use different,
specialized filtering for these.

Best regards,
Zoltan


On Wed, Sep 4, 2013 at 8:39 AM, Wonsuk Lee <wonsuk11.lee@samsung.com> wrote:
> Hi. Editors for Messaging, Contacts, Telephony and all.
>
> In the WG f2f meeting in last week, Mozilla introduced the draft of DataStore API. This spec could cover basic operations (e.g. get, add, update, remove etc) for data handling which should be supported by some of our specs(e.g. Messaging, Contacts, Telephony and extra). I think it is good idea because developer can use same APIs for handling data even among different API specs. So it would be more convenient for them.
>
> But for using this spec, firstly we need to review this whether current DataStore API is appropriate to handle data for existing our draft including Messaging, Contacts and Telephony or not.
> In addition, I would like to get feedback for scope of DataStore API. In the meeting, Giri asked a question whether we could use this for gallery API as well or not.
>
> What do you think?
>
> Kr, Wonsuk.
>
>
>> -----Original Message-----
>> From: Mounir Lamouri [mailto:mounir@lamouri.fr]
>> Sent: Tuesday, August 27, 2013 10:27 PM
>> To: public-sysapps@w3.org
>> Subject: Introducing the DataStore API
>>
>> Hi,
>>
>> You can read this wiki page to learn more about the DataStore API:
>> https://wiki.mozilla.org/WebAPI/DataStore
>>
>> I will introduce it this afternoon after lunch if we are not behind
>> schedule :)
>>
>> Cheers,
>> --
>> Mounir
>
>

Received on Wednesday, 4 September 2013 12:38:27 UTC