- 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>
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