Skip to content
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

coma Scope #3

Open
karlbennett opened this issue Sep 10, 2013 · 3 comments
Open

coma Scope #3

karlbennett opened this issue Sep 10, 2013 · 3 comments

Comments

@karlbennett
Copy link
Owner

The scope of the first iteration of coma should be decided before we begin.

Acceptance Criteria

  1. All contributors agreeing on the first set of core features coma should provide.

Related Tickets
#4 Check streaming access of different sources

@karlbennett
Copy link
Owner Author

fedons

So, how does it choose what to play? Also, does the stream go "through" the app or is it just a "remote control" (like with grooveshark)?

So how do the rest of you feel about fedons questions? As well as you fedons. Should we increase the scope to allow track selection?

Also should all the playback be done within coma it's self? It might simplify things to delegate playback to the different sources since most of them already have that functionality.

The things to consider for this are:

Delegating playback to the source

  1. We don't have to write our own playback code.
  2. We will have to write browser extensions for all the different sources to manipulate their web interfaces.
  3. Will we stick with one supported browser or write extensions for a few? PhantomJS is unfortunately out because it doesn't support Flash.
  4. Using browser extensions will make the playback "code" much more portable across platforms.

Centralising the playback within coma

  1. We will have to learn FFMPEG. There is a Go wrapper, but I doubt it abstracts much of the pain away.
  2. We will have to use some form of native playback for local files, though this could be delegated again to something like mplayer.
  3. Internal playback means less dependencies e.g. a browser. This will allow coma to be installed on headless servers.
  4. Internal playback means we will have to use the API's of the different remote sources, this will limit the sources we can use, but could simplify the implementation of the source API.

@fedons
Copy link
Collaborator

fedons commented Sep 14, 2013

I also like the second option more. But does grooveshark let you stream their music from a 3rd party app?

Spotify has got this: https://developer.spotify.com/technologies/libspotify/, but it only works with premium accounts.

@karlbennett
Copy link
Owner Author

That sounds like a ticket (#4) to me :)

@ghost ghost assigned fedons and karlbennett Sep 14, 2013
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants