Re: Data models and filtering (was: Re: Contacts API draft)

On Fri, Jan 4, 2013 at 12:44 PM, Jonas Sicking <jonas@sicking.cc> wrote:
> 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.

If you want to use it in polling mode, it's not battery friendly.
I abandoned/changed the idea for a different reason, though: this
model is good for low-pass filtering (avoiding flooding with events),
but not good for saving battery. For that, we'd need a mechanism to
sync the data updates (and other things) across the whole system,
similar to synchronizing keep-alive timers, so that every app would
wake up once in a while and update its data (not all at once, but
spread over a contiguous small period of "update-time"). An app would
rather want to announce exemption from that general rule imposed by
the system (maybe user-configurable), rather than controlling itself
the update period which will lead to a stochastic distribution of
wake-ups. The API could stay, with this changed semantics (instead of
"I don't want data sooner than this period" to "I want my data at
least this often, really, please - if possible").

>
>>      /** 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 agree.

>
> I'm also not sure I understand the reason for applying complex filters
> to change notifications.

Probably we don't need complex filters. AbstractFilter can also mean a
very simple filter. There  was a lack of explanation indeed. Moreover,
apart from a few applications, e.g. vehicle info API, apps won't need
filtering at all, and it's not expected to be supported since it's
"optional" to call and also to implement.

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

For watching changes, this would be probably enough.
BTW this is not that different from the AbstractFilter way of saying
it, as the implementation would end up constructing that list anyway.
Only that it permits more complex filters, which makes it more
difficult to implement.


Back to the use cases, IIUR yours, you just wanted to ship over data
from RIL and other places to JS side. This is similar to the pattern
used in Telephony middleware for getting SMS and call history from the
modem or low-middleware buffer (with different requirements, related
to certifications) to an application side database. Once a data is
read, it is deleted from the buffer. So you only get new data. This
model should have a lot simpler API, without any filtering, just for
getting all new data all the time.

This is different from the case when we have a native middleware/app
system with web runtime as well, and we want to keep the (same) data
somewhere (close to the source), and only expose data models needed
for the apps to the "other side". This also involves an efficient IPC
and a more sophisticated notification and sync mechanism. Much more
complex scenario.

Since these two are so different, I agree they should be in different API.
For simplicity, let's start with the first.
However, it would be good to specify it as a generic interface, rather
than repeating the full pattern in every API.

Best regards,
Zoltan

Received on Monday, 7 January 2013 07:37:29 UTC