Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Incomplete methods list of WebRTC #427

Open
dontcallmedom opened this issue Jun 12, 2019 · 3 comments
Open

Incomplete methods list of WebRTC #427

dontcallmedom opened this issue Jun 12, 2019 · 3 comments

Comments

@dontcallmedom
Copy link

The report on WebRTC implementation is incomplete as it does not include all the latest additions to the WebRTC IDL from spec.

Is there any way and interest to collect data based on authoritative IDL rather than what browsers currently ship? (I would find it useful for my reuse of confluence data)

Is this related to mdittmer/web-apis#34 ?

dontcallmedom added a commit to dontcallmedom/webrtc-impl-tracker that referenced this issue Jun 12, 2019
Otherwise, features with zero implementations are likely to be omitted

See also GoogleChromeLabs/confluence#427
@lukebjerring
Copy link
Collaborator

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

@foolip
Copy link
Member

foolip commented Jun 19, 2019

@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?

@dontcallmedom
Copy link
Author

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)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants