Closed jan-ivar closed 4 months ago
In the prior meeting, a comment was made that some of the proposed 'sending' stats may not be known, and that coercing a boolean value could cause a problem. Is this a real problem, or can robust defaults be chosen that will not mislead applications?
stats.estimatedSendRate; //nullable stats.isSendingDataLimited; // default false stats.isSendingServerLimited; // default false stats.inSendingSlowStart; // default false stats.blockedFramesCount; // default 0
If unavailable stats are mostly a problem at connection start, then defaults reflecting initial state should work.
Adding a =
default value in WebIDL is another way to guarantee the member's presence besides required
(they cannot have both). Both tools were designed for inputs but I think defaulting a lot of these to = 0
accomplishes the same signal as required
would (in lieu of a getStats algorithm that details what MUST be filled in and how). For counters this indicates the starting value, which I think has some reader value.
(I've answered about the specific stats in #603)
I'm confused, I thought we wanted to make those non-required since we can't consistently expose all of the TCP stats on all platforms?
https://w3c.github.io/webtransport/#dictdef-webtransportconnectionstats says: "The dictionary SHALL have the following attributes:" which means all stats members are required to be filled in by the user agent.
Some specs use the WebIDL
required
keyword to help denote this. I think this would help readers.