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

Sysex access information in MIDIPort? #136

Open
qdot opened this issue Apr 6, 2015 · 4 comments
Open

Sysex access information in MIDIPort? #136

qdot opened this issue Apr 6, 2015 · 4 comments
Labels
category: new feature https://www.w3.org/policies/process/#class-4 Needs Edits https://speced.github.io/spec-maintenance/about/ Priority: Soon https://speced.github.io/spec-maintenance/about/
Milestone

Comments

@qdot
Copy link

qdot commented Apr 6, 2015

Due to the fact that a MIDIPort object can outlive a MIDIAccess object, we could have ports that are created, but whether or not they support sysex is opaque unless you actively open and call send on them with a sysex message. It also means that we could fall into issues like ports being created between two MIDIAccess objects with differing sysex permissions, and having a problem telling which is which.

I have no idea exactly how you'd get into that situation, but it could happen with the way I'm translating the spec as it is at the moment. Would it be worth it to push that info into ports, or is that overkill?

@cwilso
Copy link
Contributor

cwilso commented Apr 6, 2015

My opinion is that it's probably overkill. Yes, it's possible to get into those two situations (1 - you don't know if the MIDIPort you have has sysex access, and 2 - you have two MIDIAccess objects, one with sysex and one without) - but only intentionally, and in short just "you shouldn't do that if you want to remember what MIDIAccess you're coming from."

@toyoshim
Copy link
Contributor

toyoshim commented Apr 7, 2015

From a viewpoint of implementation, it's easy to expose it as boolean MIDIPort#sysexEnabled.
So, if it is convenient for web developers, I'm fine with adding it. Also, if the idea to allow sysex permission port by port revives, the attribute will be needed.

@cwilso cwilso added the Needs Edits https://speced.github.io/spec-maintenance/about/ label Jun 2, 2015
@cwilso cwilso added this to the V1 milestone Jun 2, 2015
@cwilso cwilso self-assigned this Jun 2, 2015
@cwilso
Copy link
Contributor

cwilso commented Jun 2, 2015

OK.

@mjwilson-google mjwilson-google added the category: enhancement https://www.w3.org/policies/process/#class-3 label Sep 13, 2023
@mjwilson-google mjwilson-google added Agenda+ https://speced.github.io/spec-maintenance/about/ and removed Needs Edits https://speced.github.io/spec-maintenance/about/ labels Oct 15, 2023
@mjwilson-google mjwilson-google added the Needs Discussion The issue needs more discussion before it can be fixed. label Sep 24, 2024
@mjwilson-google
Copy link
Contributor

TPAC 2024 notes:

Firefox and Chromium are both still positive for this change.

@mjwilson-google mjwilson-google added Needs Edits https://speced.github.io/spec-maintenance/about/ and removed Agenda+ https://speced.github.io/spec-maintenance/about/ Needs Discussion The issue needs more discussion before it can be fixed. labels Sep 24, 2024
@mjwilson-google mjwilson-google added category: new feature https://www.w3.org/policies/process/#class-4 Priority: Soon https://speced.github.io/spec-maintenance/about/ and removed category: enhancement https://www.w3.org/policies/process/#class-3 labels Nov 27, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
category: new feature https://www.w3.org/policies/process/#class-4 Needs Edits https://speced.github.io/spec-maintenance/about/ Priority: Soon https://speced.github.io/spec-maintenance/about/
Projects
None yet
Development

No branches or pull requests

4 participants