[ABANDONED] [WebMIDI] Support the legacy MIDIAccess port API.

[WebMIDI] Support the legacy MIDIAccess port API.

[1] introduced MIDIInputMap and MIDIInputPort and MIAIAccess.input and
MIDIAccess.output became properties of those types. The change broke the
previous API: they were functions returning sequences.
This CL restores the legacy API while supporting the new one. This is for
a smooth migration and should be removed in the near future.

1: https://codereview.chromium.org/513203002/

BUG=341423

[yhirano, 2014-09-02 05:54:25]

yhirano@chromium.org changed reviewers:
+ haraken@chromium.org, toyoshim@chromium.org

[yhirano, 2014-09-02 05:54:26]

This CL depends on https://codereview.chromium.org/483163003/ and
https://codereview.chromium.org/513203002/ .

[haraken, 2014-09-02 07:26:16]

not LGTM. The CL adds too much hacky code in custom bindings.

Why do we need such a hacky code to support both the old API and the new API?

[yhirano1, 2014-09-02 07:29:29]

The old API: access.inputs is a function that returns a list of MIDIInput.
The new API: access.inputs is an attribute of type MIDIInputMap.

The only idea I can think of to support both APIs is to install map attributes
to the function and that's what this CL does.

[haraken, 2014-09-02 07:45:15]

On 2014/09/02 07:29:29, yhirano1 wrote:
> The old API: access.inputs is a function that returns a list of MIDIInput.
> The new API: access.inputs is an attribute of type MIDIInputMap.
> 
> The only idea I can think of to support both APIs is to install map attributes
> to the function and that's what this CL does.

It seems to me that you're taking a strange deprecation step. Do you know any
Web IDL attribute whose return type has changed (how did they do that)?

[yhirano, 2014-09-03 07:16:39]

On 2014/09/02 07:45:15, haraken wrote:
> On 2014/09/02 07:29:29, yhirano1 wrote:
> > The old API: access.inputs is a function that returns a list of MIDIInput.
> > The new API: access.inputs is an attribute of type MIDIInputMap.
> > 
> > The only idea I can think of to support both APIs is to install map
attributes
> > to the function and that's what this CL does.
> 
> It seems to me that you're taking a strange deprecation step. Do you know any
> Web IDL attribute whose return type has changed (how did they do that)?

Hmm. I could not find any example. toyoshim@, do you know?

[Takashi Toyoshima, 2014-09-03 07:45:34]

I have no good example.
If we already shipped the API, we consider to use different names for the new
replacing functions. But we didn't and decide to keep on using the simple names.
We just want to support both just for one chromium milestone, and will remove
this after 6 weeks. Supporting both API is not mandatory, but it would be nice
to have for a while to advertise the API change.

fyi, there were some histories as
https://github.com/WebAudio/web-midi-api/issues/2
https://github.com/WebAudio/web-midi-api/pull/82

[haraken, 2014-09-03 07:56:21]

haraken@chromium.org changed reviewers:
+ abarth@chromium.org, jochen@chromium.org, tkent@chromium.org

[haraken, 2014-09-03 07:56:22]

On 2014/09/03 07:45:34, Takashi Toyoshima (chromium) wrote:
> I have no good example.
> If we already shipped the API, we consider to use different names for the new
> replacing functions.

Yeah, that's a common approach.

> But we didn't and decide to keep on using the simple names.
> We just want to support both just for one chromium milestone, and will remove
> this after 6 weeks. Supporting both API is not mandatory, but it would be nice
> to have for a while to advertise the API change.

As far as I know, this is the first attempt that takes this approach, and that's
exactly why I'm concerned about the approach. If we follow the convention of API
deprecation process, we should either:

- use different names for the old API and the new API, and then deprecate the
old API.

- or change the old API to the new API in one go.

I'd delegate the decision to API owners.

+jochen, +abarth, +tkent-san

[jochen (gone - plz use gerrit), 2014-09-03 08:04:51]

i'd rather avoid custom bindings.

do we have some numbers how much usage those APIs have?

[tkent, 2014-09-03 08:08:28]

IMO, we should not take care of compatibility of unshipped features.

[jochen (gone - plz use gerrit), 2014-09-03 08:13:28]

On 2014/09/03 at 08:08:28, tkent wrote:
> IMO, we should not take care of compatibility of unshipped features.

oh, it's unshipped? Yes, in that case please just update the API and do not add
compatibility/custom code.

[Takashi Toyoshima, 2014-09-03 08:14:12]

I have no real data for the usage, but the number should be limited since the
feature is disabled unless a user specify --enable-webmidi.
As far as I know, the approach Haraken said is for a shipped API. We started
implementation behind a flag for sending feedbacks to the spec, so the API can
be changed, and should not care for compatibility until is is shipped. To make
the spec more stable is one of our major goal.

[haraken, 2014-09-03 08:16:08]

On 2014/09/03 08:14:12, Takashi Toyoshima (chromium) wrote:
> I have no real data for the usage, but the number should be limited since the
> feature is disabled unless a user specify --enable-webmidi.
> As far as I know, the approach Haraken said is for a shipped API. We started
> implementation behind a flag for sending feedbacks to the spec, so the API can
> be changed, and should not care for compatibility until is is shipped. To make
> the spec more stable is one of our major goal.

Just to be clear:

For a shipped API, we normally use different names for the old API and the new
API and then deprecate the old API. For an unshipped API, we just update it in
one go.

[Takashi Toyoshima, 2014-09-03 08:17:21]

Ok, agreed. We'll just remove the old API.

Hirano: Thank you for writing this patch, but as we discussed, we'll go without
this CL.

[yhirano, 2014-09-03 08:23:00]

On 2014/09/03 08:17:21, Takashi Toyoshima (chromium) wrote:
> Ok, agreed. We'll just remove the old API.
> 
> Hirano: Thank you for writing this patch, but as we discussed, we'll go
without
> this CL.

Got it. Thanks, all.