The API is designed in a way that we must get the kind right in order to implement other parts of the API. The reason is that kind is a parameter of MediaSession constructor and defaults to content so at least content type needs to be implemented in order to be forward compatible.
I wonder if we could introduce a defaultkind which would associate the created session with the default UA session. That way, a UA could not expose kind if it is not fully and properly implemented and expose other parts of the API. This behaviour would be feature detectable and forward compatible.
Practically, the rationale here is that MediaMetadata sounds like a great feature to ship on mobile but it is blocked by kind. The downside is that we are exposing an undefined behaviour in the spec and we will no longer make sessions defaulting to content which means developers will have to make a conscious decision if they want another type than default. Arguably, it can be a good thing.
From @mounirlamouri on May 18, 2016 17:2
The API is designed in a way that we must get the
kindright in order to implement other parts of the API. The reason is thatkindis a parameter ofMediaSessionconstructor and defaults tocontentso at leastcontenttype needs to be implemented in order to be forward compatible.I wonder if we could introduce a
defaultkindwhich would associate the created session with the default UA session. That way, a UA could not exposekindif it is not fully and properly implemented and expose other parts of the API. This behaviour would be feature detectable and forward compatible.Practically, the rationale here is that
MediaMetadatasounds like a great feature to ship on mobile but it is blocked bykind. The downside is that we are exposing an undefined behaviour in the spec and we will no longer make sessions defaulting tocontentwhich means developers will have to make a conscious decision if they want another type thandefault. Arguably, it can be a good thing.@foolip, WDYT?
Copied from original issue: WICG/mediasession#128