New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Generic API and Relax-Hub.com support #122

Merged
merged 7 commits into from Jun 9, 2015

Conversation

Projects
None yet
2 participants
@feedbee
Collaborator

feedbee commented Apr 26, 2015

First of all this PR presents universal generic API, that any player can use on it's side to integrate with the extension. It can reduce count of service-specific files.

The first service, which already have implemented this API, is my Relax-Hub.com.

Generic API based on document Media Events (MediaPlayPause, MediaStop, MediaPrev, MediaNext).

I already use this feature with my service (locally-loaded) and would be glad to see it merged and updated on the Store.

May be it will be useful to add information about generic API to README. On service's side integration code looks like this:

// Key Socket Media Keys Chrome extension generic API event habdlers
// https://chrome.google.com/webstore/detail/key-socket-media-keys/fphfgdknbpakeedbaenojjdcdoajihik?hl=en
document.addEventListener("MediaPlayPause", function () {
    player.Toggle();
});
document.addEventListener("MediaStop", function () {
    player.Stop();
});
@borismus

This comment has been minimized.

Show comment
Hide comment
@borismus

borismus Apr 30, 2015

Owner

@feedbee I think this is a great start. How about an even more generic approach. Keysocket parses the page, looks for a custom meta tag, let's say <meta name="mediacontrols">. Then, keysocket would have to parse each page and see if this meta tag exists. If it does, it expects MediaPlayPause, etc events to be handled and injects keysocket-generic-api.js.

We'd have to experiment a bit around how much performance overhead the Keysocket parsing would incur, but it would allow for pages to enable media keys without requiring any changes to the extension.

Owner

borismus commented Apr 30, 2015

@feedbee I think this is a great start. How about an even more generic approach. Keysocket parses the page, looks for a custom meta tag, let's say <meta name="mediacontrols">. Then, keysocket would have to parse each page and see if this meta tag exists. If it does, it expects MediaPlayPause, etc events to be handled and injects keysocket-generic-api.js.

We'd have to experiment a bit around how much performance overhead the Keysocket parsing would incur, but it would allow for pages to enable media keys without requiring any changes to the extension.

@feedbee

This comment has been minimized.

Show comment
Hide comment
@feedbee

feedbee Apr 30, 2015

Collaborator

I support the core idea to give control over Media Events activation to player instead of hardcoded list in manifest. But the way to do it, I think, should be a little bit different.

What if a page adds/removes player (multimedia element) dynamically? It can be SPA, for example. Parsing meta is happen only on the page loading, so dynamically added players will be missed.

To get information about Media Event support, extension can listen for MediaControlled and MediaUncontrolled events on all opened tabs through content script. After MediaControlled event received, the page will be treated as Media Events supporting. After MediaUncontrolled event received, the page is treated as Media Events non-supporting.

By the way, parsing meta tag can be an addition to event-based approach. I think that performance impact of parsing meta tags in all pages will be imperceptible. Meta tag name should be "media-controlled" as more semantical: <meta name="media-controlled">.

The only drawback of this case if tabs permission.

Collaborator

feedbee commented Apr 30, 2015

I support the core idea to give control over Media Events activation to player instead of hardcoded list in manifest. But the way to do it, I think, should be a little bit different.

What if a page adds/removes player (multimedia element) dynamically? It can be SPA, for example. Parsing meta is happen only on the page loading, so dynamically added players will be missed.

To get information about Media Event support, extension can listen for MediaControlled and MediaUncontrolled events on all opened tabs through content script. After MediaControlled event received, the page will be treated as Media Events supporting. After MediaUncontrolled event received, the page is treated as Media Events non-supporting.

By the way, parsing meta tag can be an addition to event-based approach. I think that performance impact of parsing meta tags in all pages will be imperceptible. Meta tag name should be "media-controlled" as more semantical: <meta name="media-controlled">.

The only drawback of this case if tabs permission.

@borismus

This comment has been minimized.

Show comment
Hide comment
@borismus

borismus Apr 30, 2015

Owner

Agree that the dynamic case can be supported with custom events which can
be handled by the extension itself. I don't think this is super high
priority though, since the dynamic control/un-control use case is unclear
to me.

Fine with the 'media-controlled' name. Agree that the tabs permission is a
drawback, but as it stands today, the list of supported players is getting
out of hand. I think the ability to add support for media keys to arbitrary
player without changing the extension is important.

-b

On Thu, Apr 30, 2015 at 2:27 PM Valera Leontyev notifications@github.com
wrote:

I support the core idea to give control over Media Events activation to
player instead of hardcoded list in manifest. But the way to do it, I
think, should be a little bit different.

What if a page adds/removes player (multimedia element) dynamically? It
can be SPA, for example. Parsing meta is happen only on the page loading,
so dynamically added players will be missed.

To get information about Media Event support, extension can listen for
MediaControlled and MediaUncontrolled events on all opened tabs through
content script. After MediaControlled event received, the page will be
treated as Media Events supporting. After MediaUncontrolled event
received, the page is treated as Media Events non-supporting.

By the way, parsing meta tag can be an addition to event-based approach.
I think that performance impact of parsing meta tags in all pages will be
imperceptible. Meta tag name should be "media-controlled" as more
semantical: .

The only drawback of this case if tabs permission.


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

Owner

borismus commented Apr 30, 2015

Agree that the dynamic case can be supported with custom events which can
be handled by the extension itself. I don't think this is super high
priority though, since the dynamic control/un-control use case is unclear
to me.

Fine with the 'media-controlled' name. Agree that the tabs permission is a
drawback, but as it stands today, the list of supported players is getting
out of hand. I think the ability to add support for media keys to arbitrary
player without changing the extension is important.

-b

On Thu, Apr 30, 2015 at 2:27 PM Valera Leontyev notifications@github.com
wrote:

I support the core idea to give control over Media Events activation to
player instead of hardcoded list in manifest. But the way to do it, I
think, should be a little bit different.

What if a page adds/removes player (multimedia element) dynamically? It
can be SPA, for example. Parsing meta is happen only on the page loading,
so dynamically added players will be missed.

To get information about Media Event support, extension can listen for
MediaControlled and MediaUncontrolled events on all opened tabs through
content script. After MediaControlled event received, the page will be
treated as Media Events supporting. After MediaUncontrolled event
received, the page is treated as Media Events non-supporting.

By the way, parsing meta tag can be an addition to event-based approach.
I think that performance impact of parsing meta tags in all pages will be
imperceptible. Meta tag name should be "media-controlled" as more
semantical: .

The only drawback of this case if tabs permission.


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

@feedbee

This comment has been minimized.

Show comment
Hide comment
@feedbee

feedbee May 1, 2015

Collaborator

Dynamic case clarification: single-page application (ex. RSS reader, social network) that adds and removes audio (podcasts) and video (youtube) players from one news to another.

And another thing I thought about tonight. Web page should register/unregister every single playing source (player). It will make possible to build global media stack management, that will not be depended on web page internal media stack implementation. But this can be done in userland using library, that will become a shim between tab level Media Events and single players on the page.

By the way, some people are already working on same ideas as you proposed. May be in close future we will have new working cross-platform standards on this things.

But now, I want to get some practical results, may be small, but real. I'll do the next:

  1. Document-level Media Events (MediaPlayPause, MediaStop, MediaPrev, MediaNext) [done].
  2. Additional document-level Media Events (MediaSound to get control over player's sound level not affecting system sound) [to think about it in future].
  3. Page registration for media control through <meta name="media-controlled"> tag [the first to do].
  4. Page registration for media control through document-level (MediaControlled/MediaUncontrolled) [the second to do].

I will extend this PR.

Collaborator

feedbee commented May 1, 2015

Dynamic case clarification: single-page application (ex. RSS reader, social network) that adds and removes audio (podcasts) and video (youtube) players from one news to another.

And another thing I thought about tonight. Web page should register/unregister every single playing source (player). It will make possible to build global media stack management, that will not be depended on web page internal media stack implementation. But this can be done in userland using library, that will become a shim between tab level Media Events and single players on the page.

By the way, some people are already working on same ideas as you proposed. May be in close future we will have new working cross-platform standards on this things.

But now, I want to get some practical results, may be small, but real. I'll do the next:

  1. Document-level Media Events (MediaPlayPause, MediaStop, MediaPrev, MediaNext) [done].
  2. Additional document-level Media Events (MediaSound to get control over player's sound level not affecting system sound) [to think about it in future].
  3. Page registration for media control through <meta name="media-controlled"> tag [the first to do].
  4. Page registration for media control through document-level (MediaControlled/MediaUncontrolled) [the second to do].

I will extend this PR.

@feedbee

This comment has been minimized.

Show comment
Hide comment
@feedbee

feedbee May 1, 2015

Collaborator

I have points 3 and 4 done. Check it out, please.

  1. Previous generic API was removed.
  2. New Media Control API was introduced. I wrote specification over this API in separated repository feedbee/web-page-media-control-api-spec. Read it, please. It would be great if you also correct it with PR, especially grammatically. I hope that the text is clear and understandable. If not, we should fix it.
  3. Implementation of new API required some code changes in background.js. I renamed activeTabs to registeredTabs everywhere to get closer to terminology of Media Focus Stack. ActiveTab has different meaning with Media Focus Stack.
  4. I fixed the bug when tab was in activeTabs array event if user moved to other non-media-controlled-URI in this tab.
  5. I switched version to 0.7.0 because of major changes.
  6. I tested everything with my Relax-Hub.com project and Yandex.Music player. You and everyone else can test it using build from my repository.
  7. I did not wrote anything about new feature in README. Please, review my changes, read the specification. If anything has to be fixed, we should discuss it. After everything will be perfect, right before merge you should update README, because my English is not very clean and this task would be done better by you.

:-)

Collaborator

feedbee commented May 1, 2015

I have points 3 and 4 done. Check it out, please.

  1. Previous generic API was removed.
  2. New Media Control API was introduced. I wrote specification over this API in separated repository feedbee/web-page-media-control-api-spec. Read it, please. It would be great if you also correct it with PR, especially grammatically. I hope that the text is clear and understandable. If not, we should fix it.
  3. Implementation of new API required some code changes in background.js. I renamed activeTabs to registeredTabs everywhere to get closer to terminology of Media Focus Stack. ActiveTab has different meaning with Media Focus Stack.
  4. I fixed the bug when tab was in activeTabs array event if user moved to other non-media-controlled-URI in this tab.
  5. I switched version to 0.7.0 because of major changes.
  6. I tested everything with my Relax-Hub.com project and Yandex.Music player. You and everyone else can test it using build from my repository.
  7. I did not wrote anything about new feature in README. Please, review my changes, read the specification. If anything has to be fixed, we should discuss it. After everything will be perfect, right before merge you should update README, because my English is not very clean and this task would be done better by you.

:-)

@borismus

This comment has been minimized.

Show comment
Hide comment
@borismus

borismus May 1, 2015

Owner

Thanks, this is amazing progress!! Left some comments on the spec.

On Fri, May 1, 2015 at 7:54 AM Valera Leontyev notifications@github.com
wrote:

I have points 3 and 4 done. Check it out, please.

  1. Previous generic API was removed.
  2. New Media Control API was introduced. I wrote specification over this
    API in separated repository feedbee/web-page-media-control-api-spec
    https://github.com/feedbee/web-page-media-control-api-spec/blob/master/README.md.
    Read it, please. It would be great if you also correct it with PR,
    especially grammatically. I hope that the text is clear and understandable.
    If not, we should fix it.
  3. Implementation of new API required some code changes in background.js.
    I renamed activeTabs to registeredTabs everywhere to get closer to
    terminology of Media Focus Stack. ActiveTab has different meaning with
    Media Focus Stack.
  4. I fixed the bug when tab was in activeTabs array event if user moved to
    other non-media-controlled-URI in this tab.
  5. I switched version to 0.7.0 because of major changes.
  6. I tested everything with my Relax-Hub.com http://relax-hub.com
    project and Yandex.Music http://music.yandex.ru player. You and
    everyone else can test it using build
    https://github.com/feedbee/keysocket/releases/tag/0.7.0-feedbee from my
    repository.
  7. I did not wrote anything about new feature in README. Please, review
    my changes, read the specification. If anything has to be fixed, we should
    discuss it. After everything will be perfect, right before merge you should
    update README, because my English is not very clean and this task would be
    done better by you.

:-)


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

Owner

borismus commented May 1, 2015

Thanks, this is amazing progress!! Left some comments on the spec.

On Fri, May 1, 2015 at 7:54 AM Valera Leontyev notifications@github.com
wrote:

I have points 3 and 4 done. Check it out, please.

  1. Previous generic API was removed.
  2. New Media Control API was introduced. I wrote specification over this
    API in separated repository feedbee/web-page-media-control-api-spec
    https://github.com/feedbee/web-page-media-control-api-spec/blob/master/README.md.
    Read it, please. It would be great if you also correct it with PR,
    especially grammatically. I hope that the text is clear and understandable.
    If not, we should fix it.
  3. Implementation of new API required some code changes in background.js.
    I renamed activeTabs to registeredTabs everywhere to get closer to
    terminology of Media Focus Stack. ActiveTab has different meaning with
    Media Focus Stack.
  4. I fixed the bug when tab was in activeTabs array event if user moved to
    other non-media-controlled-URI in this tab.
  5. I switched version to 0.7.0 because of major changes.
  6. I tested everything with my Relax-Hub.com http://relax-hub.com
    project and Yandex.Music http://music.yandex.ru player. You and
    everyone else can test it using build
    https://github.com/feedbee/keysocket/releases/tag/0.7.0-feedbee from my
    repository.
  7. I did not wrote anything about new feature in README. Please, review
    my changes, read the specification. If anything has to be fixed, we should
    discuss it. After everything will be perfect, right before merge you should
    update README, because my English is not very clean and this task would be
    done better by you.

:-)


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

@feedbee feedbee referenced this pull request May 1, 2015

Merged

Update README.md #1

@feedbee

This comment has been minimized.

Show comment
Hide comment
@feedbee

feedbee May 8, 2015

Collaborator

I've finished with this PR. Extension tested in few days by me with Relax Hub and Yandex.Music. Web Page Media Control API v0.4 implemented. The only thing that is not done, is description of new feature in README. Boris, please, merge it or give me your response. Improvements of API text are still appreciated. And thank you for assistance with API.

Collaborator

feedbee commented May 8, 2015

I've finished with this PR. Extension tested in few days by me with Relax Hub and Yandex.Music. Web Page Media Control API v0.4 implemented. The only thing that is not done, is description of new feature in README. Boris, please, merge it or give me your response. Improvements of API text are still appreciated. And thank you for assistance with API.

@borismus

This comment has been minimized.

Show comment
Hide comment
@borismus

borismus May 15, 2015

Owner

Valera, this is excellent. Could you also setup a simple example player
that can be used to show music player developers how they can integrate
with this extension?

Thanks,
-b

On Fri, May 8, 2015 at 9:56 AM Valera Leontyev notifications@github.com
wrote:

I've finished with this PR. Extension tested in few days by me with Relax
Hub and Yandex.Music. Web Page Media Control API v0.4
https://github.com/feedbee/web-page-media-control-api-spec/tree/v0.4
implemented. The only thing that is not done, is description of new feature
in README. Boris, please, merge it or give me your response. Improvements
of API text are still appreciated. And thank you for assistance with API.


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

Owner

borismus commented May 15, 2015

Valera, this is excellent. Could you also setup a simple example player
that can be used to show music player developers how they can integrate
with this extension?

Thanks,
-b

On Fri, May 8, 2015 at 9:56 AM Valera Leontyev notifications@github.com
wrote:

I've finished with this PR. Extension tested in few days by me with Relax
Hub and Yandex.Music. Web Page Media Control API v0.4
https://github.com/feedbee/web-page-media-control-api-spec/tree/v0.4
implemented. The only thing that is not done, is description of new feature
in README. Boris, please, merge it or give me your response. Improvements
of API text are still appreciated. And thank you for assistance with API.


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

@borismus

This comment has been minimized.

Show comment
Hide comment
@borismus

borismus Jun 9, 2015

Owner

Valera, I was hoping to write the sample myself but just haven't had time. I'll merge this for now since it seems to work, but an updated to the documentation or writing a sample would be greatly appreciated.

Owner

borismus commented Jun 9, 2015

Valera, I was hoping to write the sample myself but just haven't had time. I'll merge this for now since it seems to work, but an updated to the documentation or writing a sample would be greatly appreciated.

borismus added a commit that referenced this pull request Jun 9, 2015

@borismus borismus merged commit 1e2950a into borismus:master Jun 9, 2015

@feedbee

This comment has been minimized.

Show comment
Hide comment
@feedbee

feedbee Jun 9, 2015

Collaborator

Boris, I'm sorry for missed answer. I started to write few samples, but have not finished this work yet. Currently I haven't enough time to finish it too, but I'll definitely get it done it a little bit later (max for a few weeks).

Collaborator

feedbee commented Jun 9, 2015

Boris, I'm sorry for missed answer. I started to write few samples, but have not finished this work yet. Currently I haven't enough time to finish it too, but I'll definitely get it done it a little bit later (max for a few weeks).

@borismus borismus referenced this pull request Dec 31, 2015

Closed

Add Bugs Music #158

@borismus borismus referenced this pull request May 2, 2016

Closed

Streamsquid.com support #178

@feedbee feedbee deleted the feedbee:generic-api-and-relax-hub-support branch May 9, 2017

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment