Re: [Task Scheduler] scheduling flexibility

Replies to Zoltan and Christophe inline.

On Tue, Nov 12, 2013 at 3:32 PM, Kis, Zoltan <zoltan.kis@intel.com> wrote:

> On Tue, Nov 12, 2013 at 4:27 PM, John Mellor <johnme@google.com> wrote:
> > We're considering implementing this API In low-privileged contexts, like
> > frequently-visited drive-by web pages, or web pages that have merely been
> > bookmarked to the device's home screen. In such contexts, if we
> implemented
> > this API we would probably never allow highPrecision even with permission
> > dialogs/infobars (instead we'd wait for a future version of Web
> > Notifications to allow setting a high precision delay).
> >
> > And using the kinds of heuristics I suggested earlier, inexact scheduling
> > might be delayed by 24 hours or longer until e.g. the device is next on
> WiFi
> > and/or plugged-in to a charger. Or we might only schedule infrequently
> used
> > web apps once a week or less.
> >
> > Are these use cases that Task Scheduler is interested in supporting?
>
> Yes, these are the default low priority use cases, which do not
> specify the 'highPriority' flag, therefore won't get any errors on
> hints override anyway.
>
> The original question was what to do with high priority apps, since
> they want to be exceptions from the general rule, and then what to do
> with possible wrongdoers.
>
> My point was that even if we don't extend the API to support raising
> errors on hints override, probably won't considerably change the UX of
> the high priority apps, therefore I conclude we don't really need the
> error support in the API, and Chris' proposal is good enough.


It makes a huge UX difference. If your alarm/calendar app tells you it's
successfully scheduled a notification, then it doesn't fire on time and you
sleep in/miss the appointment, you'll send hatemail/one-star reviews to the
app author. It's much better for the app to tell you "this feature isn't
supported in your browser" (or fall back to some different mechanism).

To be clear, I'm talking about immediately rejecting the promise returned
from add if we know in advance that we won't allow it. I'm not talking
about detecting cases where we allow a highPrecision alarm, but then it
gets delayed unexpectedly (e.g. the device was off) - in such cases it
would probably be reasonable to run the alarm as soon as possible, and let
JS notice that the time is wrong and handle it accordingly.


> However,
> it is not a big deal to implement that error if you need it (just that
> I was not convinced it's really useful, and in addition it takes a big
> deal of explanation about the possible circumstances of delivering
> it).
>
> >
> >> Should we specify such delay range in the doc, at least for high
> >> precision?
>
> But again, should we mention a delay range in the spec for high priority
> apps?
>
> Thanks,
> Zoltan



On Tue, Nov 12, 2013 at 3:26 PM, Christophe Dumez <ch.dumez@samsung.com>
 wrote:

>
> On 11/12/2013 07:08 AM, John Mellor wrote:
>
> 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
>

With geolocation, high accuracy sensors often provide low accuracy data due
to physical constraints, so apps already have to handle getting low
accuracy results, hence this is a reasonable fallback. Whereas with
highPrecision alarms, most of the use cases for highPrecision are
completely different from inexact scheduling, and it is generally not a
useful fallback.

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

By "throw an error", I just mean immediately reject the promise (call the
onRejected callback passed to Promise.then/catch, if any). If the author
doesn't provide an onRejected callback, nothing happens.


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

Ah, I hadn't realised it would be a named parameter (as part of the
dictionary). That is indeed more readable than I imagined. Does this mean
data now has an additional level of nesting, i.e. add(time,
{myjson:"",...}) is now add(time, {data:{myjson:"",...}})?


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