requestMediaKeySystemAccess()'s supportedConfigurations parameter should not be optional

[ddorwin]

Currently, requestMediaKeySystemAccess() can be called with just a Key System name. However, I cannot think of a valid use case where an application should not also be providing at least a content type. There is no point in getting a MediaKeySystemAccess or MediaKeys object that cannot be used with the content. Supporting the single parameter version just adds complexity to the specification (a branch and extra algorithm) and implementations. We should make supportedConfigurations required.

[heff]

+1

[ddorwin]

The next questions are:

1. Can the sequence can be empty?
2. Can the individual dictionaries in the sequence be empty?

I think #1 should be "No." We don't allow empty sequences, arrays, or strings elsewhere in the spec.

For #2, I don't think the dictionaries can technically be empty because a few of the members have default values.

We could consider requiring values for other members, though there are legitimate reasons for them to be empty. For example, no audio or video track. Even initDataTypes could reasonably be empty if an application only wanted to load existing sessions.

Should we just require a sequence with >= 1 elements, regardless of what they contain? I think this still achieves the simplification we're looking for, but it is a bit weird that the following is valid (and the workaround to removing optional from the parameter.

navigator.requestMediaKeySystemAccess("org.w3.clearkey", [ { } ]);

[ddorwin]

The complexity of the single-parameter version also trickles down to MediaKeySystemAccess, which may return null from getConfiguration() because of this case.

[ddorwin]

As discussed in the telecon this morning, I will implement this. For now, we will allow empty dictionary(ies) (e.g. [ { } ]) because it is simpler from a spec and implementation perspective. Requiring the parameter at least means that the author has to think about this parameter (in addition to simplifying the spec and implementations as previously discussed).