Make a principled decision about which fields to accept as Promises #659
Labels
spec
Relates to the spec
Comments
|
The motivation is that to compute some of those values they need to make a network roundtrip. If they provide them via promises, that network roundtrip can overlap the network roundtrip[1] for fetching things like the worklet scripts and trusted signals.... Of course, the way the spec is written, we probably block before doing those script + trusted signals fetches anyway... [1] And also starting of utility processes, which can be slow on some platforms. |
|
I filed #662 to have the spec explain this overlapping, but I think this issue deserves to be separate to track adding an explanation of why this is the right set of fields to expect to need to overlap. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
#655 makes several fields of
AuctionAdConfiginto Promises, but not all of them. Apparently this is based on industry feedback and some extrapolation. We should figure out the principle behind that extrapolation, and make sure it's something that we'd expect developers to have some intuition about. (We don't want them to have to consult the documentation each time they want to pass a Promise to a field.) Then we should go through the rest of the fields again to see if their types are all consistent with that principle.It's always possible for developers to delay the call to
runAdAuction()until the Promises are resolved, so presumably part of the need was about letting some component auctions start before others? But I don't see timeouts about that in the spec?The text was updated successfully, but these errors were encountered: