Re: [Task Scheduler] scheduling flexibility

On 11/12/2013 10:28 AM, Christophe Dumez wrote:

On 11/12/2013 07:08 AM, John Mellor wrote:
Skipping the user notification variant for now seems reasonable - it would probably be best to integrate that into a v2 Web Notifications API.

However I'm worried about highPrecision serving as a hint. If your app needs highPrecision, it's often essential that the timer happens at that exact moment, and inexact scheduling often wouldn't be useful. Hence I'd rather have add(...) throw an error if you request highPrecision and it gets denied (the app can of course catch this and add a non-highPrecision alarm if that would be good enough). This should be easy, since add already returns a Promise that can fail with QuotaExceededError or UnknownError; we just need to add a new HighPrecisionDeniedError.

I guess could be convinced either way. The reason I proposed to use it as a hint and not throw was to match an existing API I am familiar with and that has pretty much the same use case: the Geolocation API:
http://dev.w3.org/geo/api/spec-source.html#high-accuracy

Also, I am not a big fan of throwing exceptions unless strictly needed because developers tend to forget about handling them.

Alternatively to throwing an exception, which is synchronous and therefore might cause trouble (if the implementation determines asynchronously if it can satisfy the highPrecision request). The client could check the highPrecision attribute on the ScheduledTask object that is returned asynchronously:

e.g.

navigator.taskScheduler.add(Date.now() + 6 * MS_PER_HOUR, {highPrecision: true; /*hint*/}).then(function(task) {
  if (task.highPrecision) // Actual value
    // Request was satisfied.
  else
    // Request was not satisfied.
});


Would this make sense?

Kr,

--
Christophe Dumez - Samsung Telecommunications America