W3C home > Mailing lists > Public > public-sysapps@w3.org > February 2014

Re: W3C Working Draft for Data Store API

From: Gene Lian <clian@mozilla.com>
Date: Mon, 10 Feb 2014 23:02:09 -0800 (PST)
To: EDUARDO FULLEA CARRERA <efc@tid.es>
Cc: public-sysapps@w3.org, Ehsan Akhgari <ehsan@mozilla.com>, Andrew Overholt <overholt@mozilla.com>, Jonas Sicking <jonas@sicking.cc>
Message-ID: <1115087900.7500466.1392102129799.JavaMail.zimbra@mozilla.com>
Hi Eduardo!

----- Original Message -----
> From: "EDUARDO FULLEA CARRERA" <efc@tid.es>
> To: "Gene Lian" <clian@mozilla.com>
> Cc: public-sysapps@w3.org, "Ehsan Akhgari" <ehsan@mozilla.com>, "Andrew Overholt" <overholt@mozilla.com>, "Jonas
> Sicking" <jonas@sicking.cc>
> Sent: Thursday, February 6, 2014 10:47:43 PM
> Subject: RE: W3C Working Draft for Data Store API

> It is ok to have to separate operations but in order to avoid duplicated
> operations we could drop 'add' with 'id' as argument and stick to:
> update (data, id)
> add (data)

Yeap! I doubt the same thing. I'll ask around why Mozilla separates
this in the first design.

> No problem to restrict the real sync to the sync() operation, but do you
> think that having 'id' and 'operation' in DataStoreChangeEvent adds any
> value when it comes to deciding when to do the sync()?

I think knowing the operation in advance could be useful. Especially,
for the 'clear' operation. Whenever, an 'clear' event occurs, the app
had better clear its local DB immediately, instead of pending more
events and sync'ing them at a time, because any further operations on
the non-existing records are in vain. This is the case for 'clear',
other apps might be focused on different operations to adjust their
behaviours.

And since 'operation' is useful to be passed, it's reasonable to pass
the corresponding ID as well. Say, if an app can pre-know which record
is removed, then it can immediately remove that from its local DB based
on the ID.

Gene
Received on Tuesday, 11 February 2014 07:02:37 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:36:19 UTC