Intent to Deprecate: MIDIMessageEvent.receivedTime attribute

[Takashi Toyoshima]

Primary eng emails

toyo...@chromium.org

Summary

Deprecate receivedTime attribute from MIDIMessageEvent.

The plan is to start showing migration message on M-53, and to remove it on M-54.

Motivation

The WG decided to remove the receivedTime attribute. This is because the attribute was introduced to represent a high-resolution timestamp for real-time MIDI processing, but DOM Event started using hi-resolution monotonic time instead of epoch time for Event.timeStamp that can cover our use-case too.

Compatibility Risk

Chrome started supporting Web MIDI including this attribute from M-43. Other browser haven't supported Web MIDI yet, but FireFox just started code-review based on the latest spec.

At this point, the risk is very low because Chrome is the only available browser. And it should be better to remove it before FireFox starts supporting Web MIDI without this attribute.

Alternative implementation suggestion for web developers

Event.timeStamp is available.

Usage information from UseCounter

Web MIDI usage (navigator.requestMIDIAccess) is still <=0.008% at peak, and the attribute usage is much smaller than the usage.

Entry on the feature dashboard

https://www.chromestatus.com/features/5665772797952000

WG discussion happened at https://github.com/WebAudio/web-midi-api/issues/145

Requesting approval to remove too?

No. will remove on M-54 under another Intent to remove request.

--

Takashi Toyoshima
Software Engineer, Google

[Philip Jägenstedt]

Removing receivedTime will make MIDIMessageEvent a bit similar to BlobEvent, but similar enough to merge them.

Can one do useful things with Web MIDI without looking at receivedTime, or what proportion of early adopters would you guess will be broken by this? To play it safe, you could make the deprecation period long enough so that stable channel data is available before the removal.

[Takashi Toyoshima]

Thank you for feedbacks.

On Wed, Jun 29, 2016 at 7:11 PM, Philip Jägenstedt <foo...@chromium.org> wrote:

Removing receivedTime will make MIDIMessageEvent a bit similar to BlobEvent, but similar enough to merge them.

Good point. I started a thread to discuss this in the WG (https://github.com/WebAudio/web-midi-api/issues/165)

BlobEvent seems to be implemented only on Firefox today, according to MDN. But only difference is data's type. Even if we can not merge them, ArrayBufferMessage sounds more consistent name.

Another idea is to use MessageEvent that is already used by WebSocket and WebRTC.

I think discussion won't be concluded soon. Let me continue to work on receivedTime deprecation first so that I can make changes step by step.

Can one do useful things with Web MIDI without looking at receivedTime, or what proportion of early adopters would you guess will be broken by this? To play it safe, you could make the deprecation period long enough so that stable channel data is available before the removal.

This attribute was defined to be used for recording incoming real-time events. But at this point, as far as I know, some launched services use Web MIDI for controlling devices, or using incoming events directly without recording. So I expect major sites won't be broken. I will add UseCounter for this attribute just in case. I will compare the usage with one of whole Web MIDI.

[Philip Jägenstedt]

On Thu, Jun 30, 2016 at 11:27 AM Takashi Toyoshima <toyo...@chromium.org> wrote:

Thank you for feedbacks.

On Wed, Jun 29, 2016 at 7:11 PM, Philip Jägenstedt <foo...@chromium.org> wrote:

Removing receivedTime will make MIDIMessageEvent a bit similar to BlobEvent, but similar enough to merge them.

Good point. I started a thread to discuss this in the WG (https://github.com/WebAudio/web-midi-api/issues/165)

BlobEvent seems to be implemented only on Firefox today, according to MDN. But only difference is data's type. Even if we can not merge them, ArrayBufferMessage sounds more consistent name.

Another idea is to use MessageEvent that is already used by WebSocket and WebRTC.

I think discussion won't be concluded soon. Let me continue to work on receivedTime deprecation first so that I can make changes step by step.

Yep, sounds good.

 

Can one do useful things with Web MIDI without looking at receivedTime, or what proportion of early adopters would you guess will be broken by this? To play it safe, you could make the deprecation period long enough so that stable channel data is available before the removal.

This attribute was defined to be used for recording incoming real-time events. But at this point, as far as I know, some launched services use Web MIDI for controlling devices, or using incoming events directly without recording. So I expect major sites won't be broken. I will add UseCounter for this attribute just in case. I will compare the usage with one of whole Web MIDI.

Yeah, a use counter is a side effect of deprecation. You'll still need to decide up front what removal date the deprecation message uses, so if the deprecation makes M53 then I'd suggest removal in M55 so that stable channel data is available first.

Philip

[Takashi Toyoshima]

Thanks,

Agreed. I'm preparing a CL for this; https://codereview.chromium.org/2099213002/

Also, we already passed the branch cut for m53. So, I'll deprecate it at m54, and remove it at m56 in the best case. 

I updated the feature dashboard too.