- From: Jonas Sicking <jonas@sicking.cc>
- Date: Fri, 4 Jan 2013 02:44:32 -0800
- To: "Kis, Zoltan" <zoltan.kis@intel.com>
- Cc: "Dumez, Christophe" <christophe.dumez@intel.com>, Tantek Çelik <tantek@mozilla.com>, EDUARDO FULLEA CARRERA <efc@tid.es>, "public-sysapps@w3.org" <public-sysapps@w3.org>, Wayne Carr <wayne.carr@intel.com>, Sakari Poussa <sakari.poussa@intel.com>, JOSE MANUEL CANTERA FONSECA <jmcf@tid.es>
On Fri, Nov 16, 2012 at 5:03 AM, Kis, Zoltan <zoltan.kis@intel.com> wrote: > /** minimum interval when update notification events can be sent > * this saves unnecessary wake-up's > * measured in milliseconds, 0 meaning no constraints > */ > attribute unsigned double minUpdateInterval; Note that we only need to fire an event the first time there are new updates available. Further changes will be automatically retrieved once the application calls getChanges(). So there's little disadvantage to notifying immediately when a change happens in the backend. > /** manually pull items changed from last sync > * PendingRequest.result will be a DataSyncItems object > * optional filter: for big data usually only filtered data is needed > */ > PendingRequest pullUpdates(optional AbstractFilter filter, > optional FilterOptions filterOptions); If we are going to support filters on the change-log notifications, then it seems better to require the app to provide the filter at the time when startTrackingChanges is called. That way we can store *less* information in the change log (only for changes that matched the filter). Otherwise we'll be forced to store *more* information in the changelog (enough that we can detect if the change matches an arbitrary filter). I'm also not sure I understand the reason for applying complex filters to change notifications. Filtering such that only changes that happen to certain fields makes sense. For example if the cached data doesn't contain any information from a particular field, then changes to that field can be ignored. But can you give an example of where you'd want filters more advanced than that? I.e. would something like startTrackingChanges(optional sequence<DOMString> propertyNames); be enough? Where propertyNames is a list of names of properties for which changes to would result in an entry being added to the change log? The default being that changes to any field would result in an entry being created. / Jonas
Received on Friday, 4 January 2013 10:45:29 UTC