Feature matrix for backends

[kingosticks]

A clear comparison of the features provided by each backend. This would save users have to install and configure a backend just to find it's missing a key feature they require. It may also prevent some user questions on why unsupported features are not working. Hopefully a suitably generic set of categories can be devised that are still useful.

Proposed matrix entries could include:

• Search
• Browse
• Playlists (or equivalent)
• User account (not always applicable)
• Paid subscription required
• Metadata
• Version compatibility
• Packaged (APT, AUR, Homebrew PyPI, etc)
• Documentation
• Tests (relevant?)

Perhaps the latest version/coverage/downloads badges could also be included.

[jodal]

I'm labeling this is a "starters" task, since in the first iteration the main work is just to gather the data.

[jcass77]

This could perhaps also be something that is added to the cookie-cutter template for README.rst so that extensions can self-document and keep this up to date?

Might be easier than trying to collate and keep up to date centrally, if I understood the intention correctly?

[jodal]

My long-term plan is to aggregate lots of information about each extension in a Mopidy package registry website. I started working on gathering the data with the mopidy-packages repo, but haven't worked on that for a year now.

I'm open to having the data distributed in each repo, but I'd like it to be so structured that we can aggregate it and do statistics on it. In other words, something like JSON files with a strict documented format, not free text in a README.

Originally, I assumed that the basic metadata would be kept in a central git repository, and the motivation for keeping it up to date would be to get marketing for your extension, as we would remove all extension listings from the docs when such a site starts existing.

[jodal]

A new extension registry is now available at https://mopidy.com/ext/. The extensions will soon be removed from the Mopidy docs.

Moving this issue to the website repo, as any work on extending the metadata on what the backends supports should happen there.