Incomplete methods list of WebRTC about confluence HOT 3 OPEN

@dontcallmedom, this actually is not related to mdittmer/web-apis#34, the web-apis repo holds a few different experiments, and the IDL-related code isn't used for Confluence. Confluence works entirely on "object graphs" collected from browsers by traversing the global object, so it doesn't include any API that has never been observed in any browser, including of course any new API surface in specs.

As @lukebjerring points out we have the idlharness.js tests, but we don't use the results of those for Confluence. In https://github.com/foolip/mdn-bcd-collector I'm looking at an approach similar to idlharness.js, generating tests from the IDL but making the checks as permissive as possible to detect support, rather than checking as many details as possible as idlharness.js does. This would feed into BCD, and my vague hope is that BCD will at some point be a better data source than Confluence and we can get similar insights from it.

@dontcallmedom how are you trying to reuse the Confluence data? Is it also for BCD?

from confluence.

Is there any way and interest

Provided I understand the question, on wpt.fyi we (cc @foolip) actually scrape authoritative IDL automatically, and use a testing framework to automatically generate tests against the browser implementations from the IDL itself.
https://github.com/web-platform-tests/wpt/blob/master/resources/idlharness.js

For WebRTC specifically, the test results are here:
https://wpt.fyi/results/webrtc?label=master&label=experimental&q=webrtc%2Fidlharness.https.window.html

from confluence.

I've been using the Confluence data to track progress of the implementations of a few WebRTC specs, e.g. https://dontcallmedom.github.io/webrtc-impl-tracker/?webrtc

What you're trying to do for BCD would be very close to the kind of high-level tracking I would use as well for this (indeed, something complementary to WPT, giving a higher level view of where we are in terms of spec implementations)

from confluence.