Plugin Distribution


#1

So in the original upstream, plugins were distributed by having the software reach out to a “packages.json” file.

How should we distribute plugins?


#2

I like Kodi’s repository model. You can add as many third party repos you want etc. It’s very much in the free and open spirit (imo).

We can have an official main repository, a testing/experimental repository etc.


#3

They host their repos on github these days. https://kodi.wiki/view/Official_add-on_repository

And then they generate zip files out of them for the official repo server: http://mirrors.kodi.tv/addons/
With the main structure file being: https://mirrors.kodi.tv/addons/krypton/addons.xml

Their current addon structure is based on XML, po and the actual addon files. https://kodi.wiki/view/Add-on_structure.
The fact that jellyfin addons can have arbitrary HTML can really mess up the settings pages. This also stops any new web app from working with the plugins.

There were some voiced to not use XML. I suppose TOML or JSON would be a possible alternative.


#4

Hosting binaries on repo.jellyfin.org would be trivial once we get a unified build set up for them and a Way for JF to pull them down.


#5

This is something I’d like to move away from. It’s a huge security issue. (Granted, plugins are usually not secure)


#6

We will need a way for jellyfin to pull down the “right” binary. Hosting is probably not an issue, it’s more in the dependency and version management. And how to let people submit for the “official” repo.


#7

While I agree it’s not great, it’s also at the users discretion to be installing plugins that aren’t from the official repo (that I sure hope isn’t malicious)


#8

Building plug-ins from source should have clear documentation on the wiki as well. It wasn’t so clear with emby.


#9

I think what could be a solution here is that probably most plugins use very few customization features, so maybe making a meta-description of configuration page (like, “show this edit box and this button, on click of that button do X in the backend”) with rendering of the settings being left to the client alleviate some of the worries, plus making the plugins to follow the general look-and-feel (and theme-ing) of the server easier.


#10

I agree that we shouldn’t host on GitHub because I hate to rely on external services, and I also think anything is better than XML. The current packages.json file is very robust and looks like a fine solution once we make changes to the included attributes - some fields just need to get removed eventually, like regInfo and price. With changes to the server and web interface we could support an arbitrary number of plugin repos but that doesn’t require any changes to the file above.

We could build the currently working plugins, build packages.json manually, and have plugins working again tomorrow as long as no code was removed from the server or web repos related to the plugins. Does anyone know if this has happened?

The one decision we need to make is how to build the metadata file. The easiest way to start would be to have each plugin repository contain plugin.json which would include all of the fields like author, description, et cetera. The one field that causes trouble is versions, which is dependent on which versions are currently built and hosted. That should probably be generated during the build step, which is slightly annoying but not terrible.


#11

#298 took out the plugin update task:

Not entirely sure on what else, because I remember we pointed it to mb3admin.local, and then we had to do something about it because people were getting a spinner as it tried to load a non-existing URL.

Some of the plugin stuff is here:

And here:


#12

I discussed some points when it comes to plugin versioning and what I think we need to establish to make sure plugins work smoothly against ABI bumps in the chat that I want to bring here.

@EraYaN proposes to check for ABI bumps automatically on each PR. I see this as a supplement to what I need.

My needs are basically two things:

  • Nightly nuget packages for plugin development.
  • Possibility to retroactively mark a max server version for a released plugin version

I have noticed that some plugins compiled against 10.0.1 still compiled fine against 10.1.0 and would probably load. This means that the 10.0.1 plugin would be compatible with 10.1.0 too.

On the opposite side, say that the same plugin has to be changed to compile against 10.2.0. Then I would mark the previous version as 10.0.1 - 10.1.0 and mark the new plugin against 10.2.0 - ?

In order to be ready at release time, the nightlies and possibly also releasing nuget packages for the next version some hours before releasing the server itself would help us ready plugins before people upgrade their server.

When a server gets upgraded, it should check the manifest, see if the installed plugins have version conflicts and if so, then depending on settings either auto-upgrade or tell user that a plugin needs to be upgraded to load.

I think this can make sure that when someone upgrades their server, the plugins also get upgraded and load their new versions, and the user doesn’t have to deal with broken plugins. :slight_smile:

I notice that there are some cases where a plugin could load and crash instead of failing to load. If this becomes a problem I think falling back to a plugin only being compatible with the current version as a fallback. Then as a part of the release process, all plugins need to be recompiled and published for the new version. The benefit here is that failing plugins would lead to plugins being pushed to get fixed up ahead of the release, since the release process would fail. :slight_smile:

EDIT: I also want to add that if each plugin has a manifest.json, then when updating the main manifest.json, it can look at each plugin’s manifest in order to get the needed metadata


#13

And about things that are not that essential to get things working, I’d really like to be able to select repos to get plugins from, as well as package signing, which would work kind of like apt-key where users can select which keys to trust themselves.

I’d also like us to not call it plugin store, but rather plugin repository. Because it’s not paid and stuff. :slight_smile:


#14

A couple of notes from chat last night (some of it has been mentioned already):

  1. Manifest should use GitHub tagged releases as basis.
  2. Minimum server version

#15

Also a potential feature request from me to consider - add ability to localize both displayed plugin name and its description.