Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Guidance on re-using/creating task sources #38

Open
tidoust opened this issue Nov 22, 2016 · 5 comments
Open

Guidance on re-using/creating task sources #38

tidoust opened this issue Nov 22, 2016 · 5 comments
Assignees
Labels
Issue: Overtaken? This is an old issue that may no longer be relevant? Status: Consensus to write We have TAG consensus about the principle but someone needs to write it (see "To Write" project)

Comments

@tidoust
Copy link

tidoust commented Nov 22, 2016

Tasks created by API specs come from a specific task source. Tasks from different tasks sources may be placed in different task queues. User agents run tasks one after the other but are free to assign different priorities to different task queues (and are free to group tasks from different task sources together).

HTML defines a few generic task sources. Some specs reuse them. WebRTC reuses the networking task source for instance. Other specs create additional task sources such as HTML which also defines the timer task source or the Generic Sensor API which defines a sensor task source.

Question is: when is it good practice to reuse an existing task source? And when is it good practice to create a new one?

Background for this question is the Presentation API. I suggested to use the networking task source because the tasks this specification creates are network-related. But is it a good idea? That task source would then be used by the Presentation API, WebSockets and WebRTC. Tasks created by WebSockets do not seem to need to run in any specific order compared to tasks created by WebRTC or the Presentation API. The networking task source is also used for image fetching, which seems unrelated as well.

Wouldn't it be preferable to create dedicated task sources when possible, and let user agents assign priorities as they want?

@annevk
Copy link
Member

annevk commented Nov 22, 2016

Basically, yes.

@travisleithead
Copy link
Contributor

@annevk I'm not so sure its a good idea to prefer adding new dedicated task queues... Doing so would increase the entropy in task queue selection, leading to more potential interoperability issues across diverse implementations.

Is there an argument for having it the other way?

@annevk
Copy link
Member

annevk commented Jul 26, 2017

When you're constrained you can selectively delay things more easily depending on what the user is doing. So you can proceed with NFC and UI interaction, but delay other things. If we coupled NFC to networking or some such, then they'd be slow together.

@torgo torgo added Status: Consensus to write We have TAG consensus about the principle but someone needs to write it (see "To Write" project) and removed Status: In Progress We're working on it but ideas not fully formed yet. labels Apr 6, 2018
@torgo
Copy link
Member

torgo commented Apr 6, 2018

Travis to write something up.

@travisleithead
Copy link
Contributor

To start the PR for this, will need to do a review of what task sources are available, and then what kinds of things are being put into those sources, and some general guidelines on when you would re-use and why you might want to make a new one :)

@hober hober self-assigned this May 18, 2020
rakuco pushed a commit to rakuco/wake-lock that referenced this issue Feb 8, 2021
This allows implementations to better decide when to run events and tasks
from this spec in relation to others, and specifying a task source is a
requirement when queuing tasks like we do [1].

[1] https://html.spec.whatwg.org/multipage/webappapis.html#event-loop-for-spec-authors

Rather than picking a generic task source from the HTML spec, we define a
new task source, the "screen wake lock task source", following the current
guidance in w3ctag/design-principles#38 (which is still open).
rakuco pushed a commit to rakuco/wake-lock that referenced this issue Feb 8, 2021
This allows implementations to better decide when to run events and tasks
from this spec in relation to others, and specifying a task source is a
requirement when queuing tasks like we do [1].

[1] https://html.spec.whatwg.org/multipage/webappapis.html#event-loop-for-spec-authors

Rather than picking a generic task source from the HTML spec, we define a
new task source, the "screen wake lock task source", following the current
guidance in w3ctag/design-principles#38 (which is still open).
rakuco pushed a commit to w3c/screen-wake-lock that referenced this issue Feb 9, 2021
…on. (#301)

This allows implementations to better decide when to run events and tasks
from this spec in relation to others, and specifying a task source is a
requirement when queuing tasks like we do [1].

[1] https://html.spec.whatwg.org/multipage/webappapis.html#event-loop-for-spec-authors

Rather than picking a generic task source from the HTML spec, we define a
new task source, the "screen wake lock task source", following the current
guidance in w3ctag/design-principles#38 (which is still open).
@torgo torgo added the Issue: Overtaken? This is an old issue that may no longer be relevant? label May 3, 2021
@plinss plinss added this to the 2022-01-17-week milestone Jan 13, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Issue: Overtaken? This is an old issue that may no longer be relevant? Status: Consensus to write We have TAG consensus about the principle but someone needs to write it (see "To Write" project)
Projects
Status: Unassigned
Development

No branches or pull requests

7 participants