MIDIPort should have a "state" attribute

[cwilso]

Need to expose whether the port is available/usable or not.

[cwilso]

For Windows, this could express the "not really available because someone else has exclusive access" state.

[toyoshim]

Hey, now I'm working on MIDIConnectionEvent for Chromium.
My implementation will have the same information internally, so exposing it is easy, and will be useful.

How about adding MIDIPort { readonly boolean online; } ?
The flag should represent new state in MIDIConnectionEvent.port on an event fired, e.g. MIDIConnectionEvent.port.online should be true on onconnect handler. Thus, you can set the same callback to onconnect and ondisconnect, and know which event happened by checking the attribute.

In JavaScript, you can keep on holding a reference to MIDIInputPort or MIDIOutputPort object that is going to offline, and the object can get back to online later when the device get online again. In that case, you can reuse the same object for the same MIDIPort. So, maybe we may want to have attribute EventHandler onconnect; even for MIDIPort.

(Note: implementation does the best to identify the device, but it might fail, e.g., if you connect the device to another physical port, implementation mistakenly think it is another device. Implementation take the best guess, but it can not be perfect)

Offline devices will not appear in MIDIInputMap and MIDIOutputMap enumeration, but MIDIAccess keeps on holding it internally, and your JavaScript code can keep on having it.

[cwilso]

Probably should call the state "connected" or "available" - "online" has a more network-y connotation.

[toyoshim]

OK, we already use the term connect and disconnect here and there. So, let's use "connected".

[cwilso]

Actually, how about

enum MIDIPortState {
"connected",
"disconnected"
};

partial interface MIDIPort {
MIDIPortState state;
};

? That leaves us free to expand later on, and mirrors the Web Audio context state.

[bome]

good idea. If we add open() and close() methods (see #75), we can use these states:

enum MIDIPortState {
  "disconnected",
  "connected", // == "closed"
  "opened"  // implies "connected"
};

Calling close() on an "opened" port will revert the state to "connected". Disconnecting a port will always change it to "disconnected" state.
Then we can just use one single event handler onstatechange instead of different handlers for the individual states.

[toyoshim]

Agreed on using enum.

On additional state, we may need more discussion about #75. open() and close() should be async APIs, so intermediate states may be needed, e.g., openning and so on. Anyway I start introducing MIDIPortState with two state, connected and disconnected, at the first implementation.
Once we decide to go or not to go on open() and close(), let's revisit to having additional states.

Hi guys, I'm curious to know what the current state (no pun intend) of all this is.

• Once we have a reference to a MIDIPort instance will we be able to keep hold of that reference throughout the lifetime of an application (e.g. through multiple connections and disconnects)?
• Will there only be an onstatechange event or will there also be events for each state?
• What is the difference between closed and disconnected, open and connected?
• We can either send/receive MIDI data to/from a device or we can't, so why not stick with the two connected and disconnected states?

Sorry for all of the questions but I'm in the process of wrapping a Dart library around Web MIDI so it would be helpful to know the direction things are moving in :)

[toyoshim]

Here are my understanding and thoughts.

The first question is related to the issue #79. We didn't make conclusion yet, but it will be alive after disconnection. It means, if browser implementation can understand that the same device is connected again, the old device gets MIDIConnectionEvent, and to work again.

For the question 2 to 4. As bome proposed, using onstatechange for all kinds of state change events sounds reasonable. Also connected and disconnected represent status that the device is connected to the pc or mobiles, or not. But it does not mean the device is actually used through the API, but just queried. Once the application starts using the device, or explicitly calls open(), the state is changed to opened. We may not introduce closed status since it is equivalent to connected as bome mentioned.

[toyoshim]

I sent a pull request that is expected to reflect discussions here.
I'd add the state attribute to MIDIPort, and introduce the onstatechange event in Chromium soon.

[toyoshim]

can we close this?