Feature request: expand backend-interrogation API

[jcass77]

It would be useful if frontend extensions could get an indication of which features are supported by each backend that has been loaded, in order to adapt the UI accordingly.

Some of this is already available in mopidy.backend.Backend:

• has_library
• has_library_browse
• has_playback
• has_playlists

This could probably be extended with things like:

• can_be_searched
• can_be_persisted (assuming core: Persist mopidy state between runs. Fix #310 #1376 lands)
• can_be_refreshed
• get_icon (pictographic representation to identify the backend on-screen).
• is_stream (gives an indication that tracks probably can't be seeked).

P.S. I think we've discussed this somewhere before but I couldn't find the relevant issue / thread just now, apologies if this is a duplicate.

[adamcik]

Most of these make sense and should be exposed in some way. The one I don't think belongs here is is_stream, I think this is more suited as a per "track" property to be honest.

[tkem]

@jcass77: I guess you're referring to #1108
In addition to the above, I'd also add a get_friendly_name(), which could be used as a user-friendly label when for example presenting a list of backends to include in a search. Eventually this could also take an optional locale parameter for localization.

[ismailof]

As I'm developing a (yet another) GUI client for Mopidy using the websockets interface, I find all af this info (bakcends available, description, capabilities) extreamly interesting.

However, I would find easier for both backends and clients to have the info attached to a Backend model instead of multiple/API changing functions. Thus, the info provided by backends can be extendable without changing the APIs, just extending the model, and there can be some optional fields (for instance, the icon) along with some other compulsory.

Then, we could get all of the info with two functions like list_backends(), and 'get_backend_info(backend)' or alike.