andpp/mopidy
1
0
Fork 0
Code Issues Pull Requests Releases Wiki Activity

docs: Fix link, add examples of URI conversion before playback

Browse Source
This commit is contained in:
Stein Magnus Jodal 2014-01-12 13:47:58 +01:00
parent cee7cc28ab
commit 351eaefbaf
1 changed files with 11 additions and 5 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

16
docs/api/backends.rst
View File

@ -18,20 +18,24 @@ URIs and routing of requests to the backend
When Mopidy's core layer is processing a client request, it routes the request When Mopidy's core layer is processing a client request, it routes the request
to one or more appropriate backends based on the URIs of the objects the to one or more appropriate backends based on the URIs of the objects the
request touches on. The objects' URIs are compared with the backends' request touches on. The objects' URIs are compared with the backends'
:attr:`~mopidy.backend.Backend.uri_scheme` to select the relevant backends. :attr:`~mopidy.backend.Backend.uri_schemes` to select the relevant backends.
An often used pattern when implementing Mopidy backends is to create your own An often used pattern when implementing Mopidy backends is to create your own
URI scheme which you use for all tracks, playlists, etc. related to your URI scheme which you use for all tracks, playlists, etc. related to your
backend. In most cases the Mopidy URI is translated to an actual URI right backend. In most cases the Mopidy URI is translated to an actual URI that
before playback. For example: GStreamer knows how to play right before playback. For example:
- Spotify already has its own URI scheme (``spotify:track:...``, - Spotify already has its own URI scheme (``spotify:track:...``,
``spotify:playlist:...``, etc.) used throughout their applications, and thus ``spotify:playlist:...``, etc.) used throughout their applications, and thus
Mopidy-Spotify simply uses the same URI scheme. Mopidy-Spotify simply uses the same URI scheme. Playback is handled by
pushing raw audio data into a GStreamer ``appsrc`` element.
- Mopidy-SoundCloud created it's own URI scheme, after the model of Spotify, - Mopidy-SoundCloud created it's own URI scheme, after the model of Spotify,
and use URIs of the following forms: ``soundcloud:search``, and use URIs of the following forms: ``soundcloud:search``,
``soundcloud:user-...``, ``soundcloud:exp-...``, and ``soundcloud:set-...``. ``soundcloud:user-...``, ``soundcloud:exp-...``, and ``soundcloud:set-...``.
Playback is handled by converting the custom ``soundcloud:..`` URIs to
``http://`` URIs immediately before they are passed on to GStreamer for
playback.
- Mopidy differentiates between ``file://...`` URIs handled by - Mopidy differentiates between ``file://...`` URIs handled by
:ref:`ext-stream` and ``local:...`` URIs handled by :ref:`ext-local`. :ref:`ext-stream` and ``local:...`` URIs handled by :ref:`ext-local`.
@ -43,7 +47,9 @@ before playback. For example:
library, but can provide additional features like directory browsing and library, but can provide additional features like directory browsing and
search. In other words, we have two different ways of playing local music, search. In other words, we have two different ways of playing local music,
handled by two different backends, and have thus created two different URI handled by two different backends, and have thus created two different URI
schemes to separate their handling. schemes to separate their handling. The ``local:...`` URIs are converted to
``file://...`` URIs immediately before they are passed on to GStreamer for
playback.
If there isn't an existing URI scheme that fits for your backend's purpose, If there isn't an existing URI scheme that fits for your backend's purpose,
you should create your own, and name it after your extension's you should create your own, and name it after your extension's