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

add WebUSB WebIDL #1712

Closed

Conversation

MarcAntoine-Arnaud
Copy link

issue #1694

@alexcrichton
Copy link
Contributor

Thanks for this! We in general only add stage 3 and beyond proposals to this repository. I can't seem to find documentation, but do you know at what stage in the standards process this proposal is at?

@MarcAntoine-Arnaud
Copy link
Author

I don't know where we can find the stage of the proposal...
But this patch don't work, I cannot access to USB feature (in the documentation generated with: cargo doc --all-features. Do you have any idea why ?

@Pauan
Copy link
Contributor

Pauan commented Aug 8, 2019

@alexcrichton I don't know what stage it is, but it is marked as Experimental on MDN, and only Chrome and Opera have support for it right now.

In addition, MDN says that it's currently at Draft status, so it's definitely not stable.

And the status section says this:

This specification was published by the Web Platform Incubator Community Group. It is not a W3C Standard nor is it on the W3C Standards Track.

@Pauan
Copy link
Contributor

Pauan commented Aug 8, 2019

I wonder if maybe we should have support for unstable APIs, perhaps behind an unstable-api feature or something like that.

And we would reserve the right to break anything behind unstable-api at any time, for any reason, even in minor releases.

@alexcrichton
Copy link
Contributor

Ok so it sounds like we shouldn't add this as-is because it's not an official spec yet, but I like the idea of having experimental specs here that we can break at any time. Prior art for that I'm aware of isn't to use Cargo features but rather RUSTFLAGS=--cfg=web_sys_unstable_apis or something like that.

That way it's a bit more experimental in that it forces consumers to always compile with the right flags. How's that sound to enable this?

@Pauan
Copy link
Contributor

Pauan commented Aug 8, 2019

How's that sound to enable this?

That sounds reasonable to me. It means that libraries will have a harder time relying upon unstable features, so they will be mostly used by applications, which is how it should be.

@MarcAntoine-Arnaud
Copy link
Author

@Pauan @alexcrichton thanks for comments.
I'm agreed it make sense to put it in unstable api.

@alexcrichton
Copy link
Contributor

This hasn't seen movement in quite some time now so I'm going to close this, feel free to resubmit it though!

@Pauan Pauan mentioned this pull request Jan 8, 2020
@alexcrichton
Copy link
Contributor

FWIW I've opened #1950 to track longer-term about how we plan to support unstable WebIDL files.

@alexcrichton alexcrichton reopened this Jan 8, 2020
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

Successfully merging this pull request may close these issues.

3 participants