search

w3ctag / design-principles

A small-but-growing set of design principles collected by the TAG while reviewing specifications
https://w3ctag.github.io/design-principles
178 stars 46 forks source link

Guidance on re-using/creating task sources #38

Open tidoust opened 7 years ago

tidoust commented 7 years ago

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 commented 7 years ago

Basically, yes.

travisleithead commented 7 years ago

@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 commented 7 years ago

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 commented 6 years ago

Travis to write something up.

travisleithead commented 6 years ago

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 :)