Re: [Task Scheduler] scheduling flexibility

Hi John,

Clearing a misunderstanding,

On Tue, Nov 12, 2013 at 6:16 PM, John Mellor <johnme@google.com> wrote:
> 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).

What I meant here was that even calendar/alarm apps would not care
much about being about max 1 second late, since that is the max
latency I expect with high priority apps from a meaningful
implementation. If that is the assumption, returning an error for
being 1 sec late cannot really be predicted at the time of call,
neither would it be too helpful.

Low priority apps will likely have much longer latency, as you
suggested. But IIUR they don't care, since they have expressed that by
not asking highPriority.

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

Yes, I have understood that correctly, but whether we really know in
advance may depend on future conditions - so there is quite some
uncertainty. But here is nothing wrong with the API semantics you
suggest (resolving Promise with error when we know that would happen),
just that it is hard to specify the behaviour in an exact manner.

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

Yes, I agree.

Regards,
Zoltan

Received on Tuesday, 12 November 2013 21:38:38 UTC