Re: Comments on the proposed DataStore API

[Gene Lian]

Don't mean to interrupt Jose's questions but since we're having this thread I'd like also to fire some questions/thoughts here:

1. Regarding the Incremental Schema, we simply consider the incremental schema adding for now. However, how can we eliminate some attributes from the schema if we're sure they are no longer used? I think we need to cover this issue as well.

2. Just like one of Jose's concerns, I'd also think the most controversial part is the redundant copy of the DB if each app has to maintain its own one (the DateStore API is playing the role of doing synchronization only). Supposing we have a Data Store called "contacts", and I can imagine there are at least 3 apps (e.g. Messaging App, Dialer App and Contacts App) which need to share the contacts data. Does that mean all the apps have to completely duplicate the DB data (so that they can build their own indexes on it), which might need 3 times storage space? Or in general each app should just maintain the DB containing only IDs and the needed indexes?

Gene

[Mounir Lamouri]

On 06/05/13 08:55, JOSE MANUEL CANTERA FONSECA wrote:
> I would like to know how that mirroring could be implemented without
> duplicating the data between the DataStore and the internal app database
> (indexedDB or whatever). Apparently with the current API design that
> cannot be done and it seems the data store would be another "table" but
> not a view over the internal app "tables".

Correct.

> Thus, if a particular application needs different indexes that would mean
> that such an application would need to get a snapshot of the DataStore and
> index such data accordingly in its own indexedDB, right?

Yes.

> When you talk about System Contacts store and System Messages store, I can
> guess you plan to expose Contacts or Messages also as DataStores, and that
> there will be application data stores and System Data Stores? Am I right?

That's the idea.

>> Why not exposing IndexedDB instead of this raw format? We didn't spend
>> too much time on this but my feeling would be that, for System
>> DataStores, that would require the System to have a copy of its storage
>> using IndexedDB while it might be in another format for real. A simple
>> format is less hard for that. Also, even for application provided
>> DataStores, you could imagine that an application is actually not using
>> IndexedDB for its storage mechanism (nowadays, in the Firefox OS
>> context, this isn't much realistic but we should try to see wider than
>> that).
>> There might also be difficulties to handle some features we want the
>> DataStore to be able to do but Jonas Sicking or Ben Turner would know
>> more about this.
>
> I would be happy to know more about that

I should let Ben or Jonas reply to that.

--
Mounir

[Mounir Lamouri]

On 07/05/13 11:41, Gene Lian wrote:
> Don't mean to interrupt Jose's questions but since we're having this thread I'd like also to fire some questions/thoughts here:
>
> 1. Regarding the Incremental Schema, we simply consider the incremental schema adding for now. However, how can we eliminate some attributes from the schema if we're sure they are no longer used? I think we need to cover this issue as well.

Given that the DataStore would only save a JS object, the schema would
have to be ensured by the application. IOW, it would be possible that
the first object is { foo: "foo" } and the second is { bar: "bar" }.

> 2. Just like one of Jose's concerns, I'd also think the most controversial part is the redundant copy of the DB if each app has to maintain its own one (the DateStore API is playing the role of doing synchronization only). Supposing we have a Data Store called "contacts", and I can imagine there are at least 3 apps (e.g. Messaging App, Dialer App and Contacts App) which need to share the contacts data. Does that mean all the apps have to completely duplicate the DB data (so that they can build their own indexes on it), which might need 3 times storage space? Or in general each app should just maintain the DB containing only IDs and the needed indexes?

Applications will not *have* to copy the contacts data, they *can* do
that for performance reasons. So, indeed, only a sub-set of the data
might be copied.

--
Mounir