Update README.md

[borismus]

Some tweaks (still not perfectly happy)
Big question: why do we need MediaControlApiInit?
Also, I think "Browser-Side Control System" is confusing: is it the thing that intercepts the keys (chrome.commands) or the extension in this case (Keysocket) ?

[feedbee]

Thank you!

1. Browser-Side Control System

This is a bad term, it's better to replace it with something less confusing. I'll try to explain what did I mean.

Media Action is an intent to start/stop/pause playback of a media source, or to choose next or previous track, or +- sound volume.

Media Control API can be used to deliver Media Actions to web page. Media Event is a carrier, it holds information about Media Action (just a message type currently). Media Event always triggered on browser side by extension (currently) or browser itself (in future). There isn't any difference for API or web page, who really triggers this event. It's obvious, that it will always be a component, that works on browser level, not on web page level.

Talking about extension, I should mention, that media keys translator (like Keysocket) is not the only one candidate to work on browser side. Right now Keysocket is main target and the reason why I do this work. The next my target is extension for client-server remote control over web page playback. I'm already working on it. This extension can use the same API in future.

So, we have some stuff that works on browser side. Than we have API. And in the end, we have a web page.

[Browser side] <--(Media Control API)--> [Web page scripts]

Browser-Side Control System is anything that works left of API. It's some kind of abstraction. Currently it is always an extension (or few different extensions in the same time), in future it can be also browser itself.

Notice: the way used to initiate Media Action (key press, or remote message, or anything else) is out of interest of this API. API's interest is to pass particular Media Action to particular web page.

2. MediaControlApiInit

MediaControlApiInit event is some sort of hack. The event tells web page that MediaControlled and MediaUncontrolled event will be handled. If MediaControlled was triggered before MediaControlApiInit, it will be missed. Extension's content script may be executed too late, even after DOMContentLoaded event on the web page triggered. If MediaControlled will be triggered too early, it will be lost.

Additionally, API guaranties that meta-tag will be parsed after MediaControlApiInit triggered. It's important if the tag is generated by the web page scripts.

But, writing this answer I've understood that MediaControlApiInit will do it's job well only in case when one and only one extension uses the API. If two or more extension use API simultaneously, the first loaded will catch MediaControlled event, but later loaded extensions will lose it. It's a problem and I'll think how to solve it.

3. What's next?

I offer to replace the term "Browser-Side Control System" to something better, than to merge this PR.

My PR#122 on Keysocket must wait at least until MediaControlAppInit problem will be resolved.

[feedbee]

I already have a solution for MediaControlApiInit issue. I'll fully remove this event and replace MediaControlled and MediaUncontrolled with single MediaControlStateChanged event. Web page will be forced to add meta tag to get under control. If web page adds or removes meta tag dynamically (to enable or disable the control in run-time), it must trigger MediaControlStateChanged event to let browser-side software know about this change. If meta tag was placed in the page initially (statically), than there is no need to trigger MediaControlStateChanged, content script will search for this tag when it will be loaded.

So, meta tag will be required to get under control initially, and meta tag manipulation + MediaControlStateChanged event will be an option to change state in run-time.

[borismus]

MediaControlStateChanged sounds like a good proposal, but can you spec out
when it fires? Looking forward to a revised version of the implementation
and the docs. Thanks!

On Fri, May 1, 2015 at 2:07 PM Valera Leontyev notifications@github.com
wrote:

I already have a solution for MediaControlApiInit issue. I'll fully
remove this event and replace MediaControlled and MediaUncontrolled with
single MediaControlStateChanged event. Web page will be forced to add
meta tag to get under control. If web page adds or removes meta tag
dynamically (to enable or disable the control in run-time), it must trigger
MediaControlStateChanged event to let browser-side software know about
this change. If meta tag was placed in the page initially (statically),
than there is no need to trigger MediaControlStateChanged, content script
will search for this tag when it will be loaded.

So, meta tag will be required to get under control initially, and meta tag
manipulation + MediaControlStateChanged event will be an option to change
state in run-time.

—
Reply to this email directly or view it on GitHub
#1 (comment)
.

[feedbee]

Yes, I'll update spec a little bit later. And now I want to finish with your corrections and merge this PR. What about replacement "Browser-Side Control System" with "Browser-Side Component"?

A Browser-Side Component is a browser itself or any extension that reacts on Media Actions and triggers Media Event inside web page.

What do you think about this? Is it confusing?

[feedbee]

I merge this PR and will update text to replace "Browser-Side Component" with "Browser-Side Component"

[borismus]

Thanks!

On Tue, May 5, 2015 at 11:27 AM Valera Leontyev notifications@github.com
wrote:

Merged #1
#1.

—
Reply to this email directly or view it on GitHub
#1 (comment)
.