Simplify MediaSession somewhat to not require audio playback

[foolip]

This is motivated by @jernoble's explanation of the iOS model, as it
does not seem like media playback is required, only an active media
session. This hasn't been verfied, however:
#9 (comment)

[marcoscaceres]

main is not very clear relative to the others. default?

[foolip]

OK, I've renamed it and also added it to the constructor. I assume that these categories are all wrong and will need be tweaked ~42 times.

[foolip]

Some out-of-band comments from @marcoscaceres:

I think it's fine, but session.activate().then(function() {...})shouldn't be needed for audio elements
i.e., you shouldn't need to .play()
I think it should work like: if the object is "controllable" (i.e., has play, pause, skip, etc.) then call those, otherwise, route them to the MediaSession

I agree, some of this stuff should happen automatically, I'm just not sure where such default behavior belongs. One could keep the association between MediaSession and HTMLMediaElement so that a session becoming active automatically plays the media element. One could also define the default behavior as a third component defined in terms of MediaSession and HTMLMediaElement.

If we start with an API that makes it possible to implement everything you want in scripts, then I'm confident we could define the defaults in terms of that API. I think this is important and could influence the shape of the API, but it isn't at the very core of things.

[richtr]

This is motivated by @jernoble's explanation of the iOS model, as it
does not seem like media playback is required, only an active media
session. This hasn't been verfied, however:
#9 (comment)

I'm not sure this is correct.

For example, see this question on StackOverflow. This answer suggests that a developer can intercept and use remote control events for another purpose (e.g. to control an ongoing slideshow) only by silently playing out some audio and intercepting that silent audio's corresponding remote control events (see the Obj-C code here). This also presumably applies to obtain hardware remote controls access too.

[richtr]

i.e., you shouldn't need to .play()

That is exactly the call required on iOS.

Perhaps there is a way around this. For example, a user agent on iOS could run a hack where it loops some local silent transient audio and then we re-route associated remote control events to MediaSession. It is a hack though. Is this how you see it working on iOS?

[foolip]

@jernoble, have you been able to verify the requirements? We're all too incompetent at writing iOS apps to try it ourselves :)

[richtr]

@foolip Would it make sense to split this in to separate PRs as follows:

PR1: WebIDL changes (i.e. the introduction of MediaSessionKind, the modification of MediaSessionState, removal of members and the overall simplification of the available events)
PR2: Any changes that related to not requiring audio playback (which is still TBD further IMO)

WDYT?

[foolip]

The removal of members is related to not requiring audio playback. Do you mean that a first PR should leave MediaSession in a state where it has no coupling at all to media playback, kind of like Android's API? I can do that, but I'd like to make progress on the core issue of what the coupling should be...

[foolip]

I have fiddled some more and am just going to go ahead and merge as I think this is a better structure for discussion. I've pointed out the issues I'm aware of, let's continue discussing in those issues.