[Bug 19762] "connect" event not logically possible, and disconnect message not present on some systems

https://www.w3.org/Bugs/Public/show_bug.cgi?id=19762

--- Comment #3 from Chris Wilson <cwilso@gmail.com> ---
First, my apologies for brusquely removing; I've had feedback that the more
implementable the spec is, the easier it is to get implementation experience.

My comment on disconnect being challenging on some underlying platforms was
referring to the fact that not all underlying systems fire disconnect events
(e.g. Windows' MIDI API, outside of the apparently-deprecated DirectMusic
APIs).  Although of course if you already had a reference to a MIDIPort, and it
was disconnected then reconnected, you could get a connect event fired on the
MIDIPort (see #2 in Comment 1 - "optionally additionally fire on MIDIPort
itself".  However, that's frankly quite a narrow scenario, and it's more
interesting to be able to get notifications for Ports you don't already have a
reference to - e.g. to update a dynamic list of currently available MIDI ports,
detect when a new controller has been plugged in, etc.  That would be much more
of a core usage scenario for a connect event.

As to "not going to magically disappear" - I don't know, honestly; we have to
explicitly define what happens in this case.  Would it be expected that the
MIDIPort becomes "active" again (e.g. you start receiving messages on an Input,
or you can once again send to an output) if it's unplugged and then replugged? 
I haven't had a chance to investigate behavior in that scenario in
Windows/CoreMIDI.

On merging connect/disconnect updates - I'm a little uncomfortable with that;
it's  much easier to write code that detects and configures a newly-plugged
controller, e.g., if you're told WHICH Port was added.  We could require the
developer to hold on to the list themselves (i.e. there is a workaround), but
it might be easier to provide this information in the first place.

If we are going to have these events, and are expecting polling to be used to
implement them in a significant scenario (e.g. "on Windows"), we really do need
to say something about such things as the latency of these events.  Polling
every MIDI device in the system once a second to implement these events seems
not necessarily worth it to me; but if we are doing that, we need to provide
definitive guidance on this, and these events should be a "MUST" not a
"SHOULD".

For all these reasons, I personally think we should postpone connection events
to a later revision; but if you want to try to address this now I'm open to
doing that.  However, what we had in there wasn't very useful, and it opened up
more questions than it resolved.

The changelists (there are actually two, as I missed a section in my first
update) are pretty easy to grab content from and push back in:

https://dvcs.w3.org/hg/audio/rev/46c470599a4b and
https://dvcs.w3.org/hg/audio/rev/b70563d39ab1

You can revert them, but then these issues need to get resolved in detail at
the same time, and I maintain that the current text's structure
(connect/disconnect fire on MIDIPort, not MIDIAccess) is not addressing the
most important use case (updating list of accessible ports).

-- 
You are receiving this mail because:
You are the QA Contact for the bug.

Received on Thursday, 1 November 2012 15:05:51 UTC