Closed saschanaz closed 1 year ago
Good point. I don't precisely remember, but I think we wanted to ensure that it was easily extensible with new codecs. However, using an enum wouldn't really make any difference to that.
We might also want to include compression parameters as part of the format
, but I can't think of any parameters that wouldn't be better placed in a second "option bag" argument to the constructor.
The W3C design principles' recommendation is to just stick with strings.
We might also want to include compression parameters as part of the
format
, but I can't think of any parameters that wouldn't be better placed in a second "option bag" argument to the constructor.
Agreed, codecs have string parameters but I don't think that's a thing for compressions.
The W3C design principles' recommendation is to just stick with strings.
It seems it's talking about C++ enums as IDL enums are still strings 🤔
Filed https://github.com/w3ctag/design-principles/issues/427 for the principles.
Currently it's accepting string, but given that the constructors throw on unsupported format, maybe it can be an enum?