Skip to content

Enslaving third party players

jphastings edited this page Sep 13, 2010 · 7 revisions

Assuming playdar had a player api (stop start pause etc) it would need to delegate playback to certain third-party apps like rd.io or spotify.

Using the third-party player as an erlang port

One approach is to spawn the third-party app in headless mode:
./rdio.exe —headless
and send it commands on stdin, receive replies on stdout.
Commands might include:

  • play
  • togglepause
  • stop
  • setvolume <1-100>
  • stat
    • which returns current NP data, position of playback (ie 120 of 300 secs) etc

stat could be emitted automatically on song change.
(edit: jwheare) stat would need to be emitted all the time if you want to have a playback progress bar in web clients.
(edit: mxcl) if playdar is controlling the player then the player shouldn’t change the track (referring to “stat could be emitted automatically…”) unless we’re sending it a playlist or somesuch.

(comment: mxcl) I’m not sure how popular this would be with third parties, ie. making a headless client. We may have to use sockets if we want a standard. However if we could make them do this, it’s my favourite.
(comment: jwheare) We need Google Wave.

Using TCP/HTTP

The third-party app would open a TCP port on localhost, or run a small http server on localhost.
Send various commands over that port.

OS specific ways

Windows messages, or use a named pipe or something.