Re: [w3ctag/design-reviews] Scheduling APIs (#338)

@kenchris 

> Generally, I think it is great to see work done in this area, but I am also a bit worried that this will make the average developer's life more complicated.
> 
> Especially, it might be hard to understand what priority to use (high, low, default) so it is important that frameworks and libraries don't force people to make that decision when not needed. 

We're hoping to change these to more semantically meaningful names to clear up some of the confusion about which priority is appropriate. [GCD](https://developer.apple.com/documentation/dispatch/dispatchqos/qosclass) has something similar now after starting with more generic names.

Also, in the current API shape priority is an optional argument that defaults to "default", which we'd expect to have similar behavior to other unprioritized methods devs currently have of scheduling script (though some of this depends on the other discussions here about integrating with other task sources).

> Also, today people use a ton of libraries and all of these might use this API internally and set their own prioritization that might conflict with what I am trying to do. So it needs to be very easy to see what a library is doing and change the priority. If every library ends up creating their own APIs for doing so, it might turn into a mess.
> 

This is on our radar as well, but it’s unclear if there’s something we can do through the postTask API and if it affects the API shape, or if we need a separate solution, such as some type of "priority sandboxing". It feels like the latter to me, especially given that controlling when 3P script runs is a problem today without the postTask API, but this still needs to be fleshed out.

> I also find the name "immediate" confusing as it doesn't run immediately, as it runs after microtasks.

I agree that a more semantically meaningful name would be helpful here, which we plan to address.

> Should it be possible to access something like the micro task queue using this API?

This might be a useful future addition. There is currently the queueMicrotask() API that does this, but adding a "microtask" priority could be beneficial in terms of creating a cohesive scheduling API.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/w3ctag/design-reviews/issues/338#issuecomment-534776292