Re: [Task Scheduler] scheduling flexibility

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.
>
> As for adding a boolean, perhaps it would be clearer to have 
> "addExact" and "addInexact"?
>
I don't think it would be clearer to add more methods. To be clear, what 
I am proposing would look like:
navigator.taskScheduler.add(Date.now() + 6 * MS_PER_HOUR, 
{requestHighPrecision: True, data: myObject});

I believe the result is readable enough, right?

Kr,

-- ,
Christophe Dumez - Samsung Telecommunications America
Boston, MA