Define tasks for state changes

[alexshalamov]

At the moment, spec has few places where state is updated without task or (state change + simple event) is fired outside of task execution scope.

According to recommendations from Anne state changes should be performed from task.

Also, spec must define what happens to tasks that are in the queue, e.g., whether those can be cancelled (removed from queue).

Example 1:

Sensor is active and update reading is queued, then error occurs and page loses visibility.
Now we have 3 tasks in queue [update sensor reading, onerror, state change to idle].

Should we process queue and don’t allow new tasks to be added from sensor? Should we 'suspend' tasks and wait when page gains visibility and then process tasks?

Example 2:

Sensor is is active, update sensor reading scheduled, then stop is called.

Two tasks in queue [update sensor reading, change state to idle]
Should we cancel queued update?

[tobie]

We'll see what the simplest solution to this is.

Given the reason of suspension (mitigate skimming) eventually allowing one reading to get through isn't an issue.

[tobie]

Example 1:
Sensor is active and update reading is queued, then error occurs and page loses visibility.
Now we have 3 tasks in queue [update sensor reading, onerror, state change to idle].

Page looses visibility is not going to queue anything afaik.

Should we process queue

Yes.

and don’t allow new tasks to be added from sensor?

Not sure what you mean by that, but the sensor can continue adding new tasks (for example if it's re-started).

Should we 'suspend' tasks and wait when page gains visibility and then process tasks?

No, they're queued and can be processed right away.

Example 2:
Sensor is is active, update sensor reading scheduled, then stop is called.
Two tasks in queue [update sensor reading, change state to idle]
Should we cancel queued update?

No.

[tobie]

Alright, so I checked with Anne and that was an excessive interpretation of his words.

Queuing tasks are really meant to handle boundary conditions with async events to maintain JavaScript's single-threaded nature. So it's essentially useful for us when passing new readings to JS.

Still checking to see if/when to apply it to events, as that part is still unclear to me.

[alexshalamov]

Anne was right, we should update states + fire event from tasks when we get some async events, e.g., from platform.

Due to single threaded nature of JS for things like start / stop, we are executing code in same call-chain, so, this issue might not be applicable.

For things that run 'in parallel', we need to queue new tasks.

[tobie]

Yeah. That's pretty much what I said. ;)