- From: <bugzilla@jessica.w3.org>
- Date: Thu, 01 Nov 2012 09:48:51 +0000
- To: public-audio@w3.org
https://www.w3.org/Bugs/Public/show_bug.cgi?id=19762
Jussi Kalliokoski <jussi.kalliokoski@gmail.com> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |jussi.kalliokoski@gmail.com
--- Comment #2 from Jussi Kalliokoski <jussi.kalliokoski@gmail.com> ---
(In reply to comment #0)
> The "connect" event as currently spec'ed isn't possible to receive (since it
> fires on the MIDIPort, which the user wouldn't have been able to create yet,
> since it's not connected).
>
> 'disconnect' is also hard if not impossible to implement on some systems.
> Suggest cutting the events.
Not really true, these events are designed for easy hot-plugging of MIDI
devices. If the program already has the MIDIPort, it's not going to magically
disappear if the associated device gets unplugged, so the "disconnect" event
gets fired, and when/if the associated device gets replugged, the "connect"
event gets fired. While not all system APIs support this, it's fairly simple to
achieve with polling, given that we place no requirements on how soon the event
must fire, so that we don't place a performance burden on the user agent.
As for the 3), I think for the MIDIAccess interface, an event that fires
whenever the ports list changes (merged disconnect and connect) should be
enough.
BTW, I'm not very happy that you went ahead and removed them from the spec.
--
You are receiving this mail because:
You are the QA Contact for the bug.
Received on Thursday, 1 November 2012 09:48:53 UTC