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
Maybe we shouldn't hog overly generic interface names? #199
Comments
jan-ivar
changed the title
Maybe don't hog overly generic interface names
Maybe we shouldn't hog overly generic interface names?
Feb 17, 2021
wilaw
added
the
Discuss at next meeting
Flags an issue to be discussed at the next WG working
label
Feb 24, 2021
wilaw
removed
the
Discuss at next meeting
Flags an issue to be discussed at the next WG working
label
Apr 13, 2021
I tend to agree. Given the name doesn't matter for people other than spec writers and spec readers, maybe prefixing with |
yutakahirano
added
the
Discuss at next meeting
Flags an issue to be discussed at the next WG working
label
Jul 15, 2021
Meeting:
|
jan-ivar
added
Ready for PR
and removed
Discuss at next meeting
Flags an issue to be discussed at the next WG working
labels
Aug 3, 2021
yutakahirano
added a commit
that referenced
this issue
Aug 17, 2021
yutakahirano
added a commit
that referenced
this issue
Aug 17, 2021
yutakahirano
added a commit
that referenced
this issue
Aug 18, 2021
yutakahirano
added a commit
that referenced
this issue
Aug 18, 2021
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
This spec grabs a few generic-sounding interface names that do not seem generic at all, like SendStream, ReceiveStream, and BidirectionalStream, none of which have constructors. They're visible on
window
; other specs wouldn't be able to reuse them.Compare to e.g. RTCRtpScriptTransform in other specs.
Should we perhaps prefix these? What prefix would we use?
WebTransportSendStream
?WTSendStream
?The text was updated successfully, but these errors were encountered: