The current work focuses on what is possible by the "platform", and this is no longer a good or advisable focus for media session today. It's holding the spec back, and the web needs to be radically more ambitious than this if it has any hope to keep pace with what's happening on native & about.
The use case document hasn't been updated in 8 years, but so much has changed. For example, "streamer" decks have become a huge product line, that countless users love and enjoy. They offer radically more controls and options than what was available historically. Most of these controls are not "platform" controls, but integrations on native apps are broadscale. Many users are also far more comfortable with advanced video conferencing, that has also much more come into being, and there's a huge array of media controls offered by these products.
It also feels like the explainer sets a low bar for what is intended to be offered:
People consume a lot of media (audio/video) and the Web is one of the primary means of consuming this type of content. However, media on the web does not integrate well with the platform. The MediaSession API helps closing the gap between the web and native with a particular focus on mobile. The spec's introduction should be updated, with a broader scope:
Similarly the spec itself restrains itself to a narrow objective of offering limited mobile platform affordances:
Media is used extensively today, and the Web is one of the primary means of consuming media content. Many platforms can display media metadata, such as title, artist, album and album art on various UI elements such as notifications, media control center, device lockscreen, and wearable devices. This specification aims to enable web pages to specify the media metadata to be displayed in platform UI, and respond to media controls that may come from platform UI or media keys, thereby improving the user experience.
All three documents (use case, explainer, intro) focus on platform UI and platform media keys. This is a great baseline (for 2018), but no longer adequate for the web to flourish and succeed, to keep pace with native. Media Sessions can and should acquire broader scope, to allow it to be more ambitious. We can and should expand the use cases offered, and have a more ambitious explainer to boot, that reflects the wide range of media controls that users today experience and do.
Re-framing the spec
I see two major shifts mediasessions could make to improve it's stance:
- De-emphasize the role of the platform.
- Stop acting as a gate-keeper of media actions, allow anything.
De-emphasize the role of the platform
I think it would be wonderful to suggest that browser extensions might be an extensible hook, that can be a way where actions and state beyond what the platform offers might be implemented (not entirely related but #229 has some extension related interests). There's countless ways extensions could contribute, but for example with Chrome's Native Messaging, it should be possible for stream deck systems to add actions not supported by the platform.
Extensions are just an example here. Perhaps the browser implements it's own RPC system to allow external agents to send commands to it (easily done on Linux by extending DBus MPRIS, for example). The spec should be expanded to be more encompassing, broadly, rather than trying to narrowly cut specific new channels.
Allow anything
Rather than narrowly specify, media-session might support extensible actions, might allow extensions or external drivers to provide whatever media session actions they want to the user agent, with the current media session perhaps becoming a starting in a broader well-known registry of actions. In #367 there's a huge array of actions which would love to get work. It's unclear what value this spec serves acting as a gatekeeper of actions. There also seems to be not a ton of energy available for adding the amazing awesome fantastic superb ideas. mediasession can (likely OUGHT) step back from this role that lacks the time to detail & service, and allow devices, platforms, systems, extensions, and others to provide what actions that they have available.
The current work focuses on what is possible by the "platform", and this is no longer a good or advisable focus for media session today. It's holding the spec back, and the web needs to be radically more ambitious than this if it has any hope to keep pace with what's happening on native & about.
The use case document hasn't been updated in 8 years, but so much has changed. For example, "streamer" decks have become a huge product line, that countless users love and enjoy. They offer radically more controls and options than what was available historically. Most of these controls are not "platform" controls, but integrations on native apps are broadscale. Many users are also far more comfortable with advanced video conferencing, that has also much more come into being, and there's a huge array of media controls offered by these products.
It also feels like the explainer sets a low bar for what is intended to be offered:
Similarly the spec itself restrains itself to a narrow objective of offering limited mobile platform affordances:
All three documents (use case, explainer, intro) focus on platform UI and platform media keys. This is a great baseline (for 2018), but no longer adequate for the web to flourish and succeed, to keep pace with native. Media Sessions can and should acquire broader scope, to allow it to be more ambitious. We can and should expand the use cases offered, and have a more ambitious explainer to boot, that reflects the wide range of media controls that users today experience and do.
Re-framing the spec
I see two major shifts mediasessions could make to improve it's stance:
De-emphasize the role of the platform
I think it would be wonderful to suggest that browser extensions might be an extensible hook, that can be a way where actions and state beyond what the platform offers might be implemented (not entirely related but #229 has some extension related interests). There's countless ways extensions could contribute, but for example with Chrome's Native Messaging, it should be possible for stream deck systems to add actions not supported by the platform.
Extensions are just an example here. Perhaps the browser implements it's own RPC system to allow external agents to send commands to it (easily done on Linux by extending DBus MPRIS, for example). The spec should be expanded to be more encompassing, broadly, rather than trying to narrowly cut specific new channels.
Allow anything
Rather than narrowly specify, media-session might support extensible actions, might allow extensions or external drivers to provide whatever media session actions they want to the user agent, with the current media session perhaps becoming a starting in a broader well-known registry of actions. In #367 there's a huge array of actions which would love to get work. It's unclear what value this spec serves acting as a gatekeeper of actions. There also seems to be not a ton of energy available for adding the amazing awesome fantastic superb ideas. mediasession can (likely OUGHT) step back from this role that lacks the time to detail & service, and allow devices, platforms, systems, extensions, and others to provide what actions that they have available.