Allow plugin updater to point to arbitrary zip file

[Krzmbrzl]

This is a continuation of the discussion that started in #4946.

Essentially the argument was brought up that it might be beneficial to let the updater point not to the Mumble plugin directly but optionally to a zip file that contains (among other things) the plugin.

[Krzmbrzl]

Having the updater only supporting exactly that one file is my problem. I would prefer if the .mumble_plugin binary could be part of another release ZIP package, so i can ship more related stuff with it (I also ship a java client that supplies information to the plugin when it runs in the mumble instance, and like i said, also the license and readme files, and some other stuff like a FlightGear-addon so flightgear can send data to the plugin).

Like this structure:

fgcom-mumble-release-1.0.0.zip
fgcom-mumble.mumble_plugin
fgcom-mumble.so
fgcom-mumble.bundle
fgcom-mumble.dll
REAMDE.md
LICENSE
radioGUI
FGFS-addon
... more stuff

This currently actually works, but it is by accident and against the specs you wrote. The updater/installer just needs to recognize if he has a ZIP file. And if so, he needs to one-time look, if the ZIP contains a file *.mumble_plugin.

@hbeni Allowing for something like this will waste bandwidth though as the only thing that will ever be used from this zip file by the updater is the Mumble plugin. Everything else will be downloaded and then discarded. That seems rather wasteful especially if you are starting to package not only some README and license files in there but also other (parts of) programs...
That seems to unnecessarily blow up the download size 🤔

In the future I am envisioning a central Mumble plugin store that will host the individual plugin files somewhere on our server such that users can access the store from within Mumble, select the plugins they want to install and do so all from within Mumble. With such a system you would also let updates be handled by this infrastructure and thus it would eliminate the double-hosting requirements you are currently experiencing.

[hbeni]

Firstly, thanks for splitting this away. We can discuss better this way :)

Allowing for something like this will waste bandwidth though

Wasted bandwith is surely something to consider down the road. Currently however, I talk about 3.8MB.
With this argument, we also would't need the "one zip for all OS/architectures" feature - because the mumble instance in question only ever needs exactly one of the compiled libraries and better would have stayed with separate files and letting the updater decide. I don't think this is desirable.

In the future I am envisioning a central Mumble plugin store that will host the individual plugin files somewhere on our server

What about the case where the plugin needs some fixed third party API and both need to be compliant?

• One example is my Flightgear addon that needs to be in sync with the UDP protocol the plugin accepts.
• A more major example will be ACRE, because it relies on a matching binary ARMA DLL plugin.
  We surely can say that the user is responsible for keeping the versions up-to-date and compatible. I just have seen a very easy option for enhanced user friendlyness (just download one file, point mumble to it, done; and for me when releasing to just put one single file online) with a very biased view of my needs/implementation.

Don't get me wrong, I just found the idea very compelling. But it certainly is in the category of "nice to have". This is surely no deal breaker. I just have to word the asset names more clearly.
Please keep the possibility that i can point the updater to a remote download URL for *.zip because on github I can't upload files of type *.mumble_plugin as release asset.<- tested, it does work

In the future I am envisioning a central Mumble plugin store that will host the individual plugin files somewhere on our server such that users can access the store from within Mumble, select the plugins they want to install and do so all from within Mumble.

Sounds cool and very user friendly! For this case, a manifest file would be even more useful to encode basic authorship and license information.

[Krzmbrzl]

Currently however, I talk about 3.8MB.

You but I can already see people putting "only" 200MB applications in their zips because of reasons and this is the kind of stuff that I want to avoid xD
And adding a fixed size-limit does not seem practical either since I don't want to restrict the size of the actual plugin binaries...

With this argument, we also would't need the "one zip for all OS/architectures" feature - because the mumble instance in question only ever needs exactly one of the compiled libraries and better would have stayed with separate files and letting the updater decide. I don't think this is desirable.

Strictly speaking this is correct. However the difference is that in the "on-zip-case" all files contained within the zip are actually Mumble-related whereas in the "put-in-what-you-want-case" this might not be the case.

What about the case where the plugin needs some fixed third party API and both need to be compliant?

Then this is out-of-scope for the plugin updater. At least for now.
Maintaining 3rdParty dependencies would require knowledge about where to put the extra files and making sure that their update works as expected as well. The complexity of such an update procedure seems to be exponential. Therefore for now Mumble will only update Mumble plugins. If you depend on a specific plugin-3rdparty-combination, then the user has to perform the updates manually.

Don't get me wrong, I just found the idea very compelling. But it certainly is in the category of "nice to have". This is surely no deal breaker.

I would also consider this to be a nice feature but I currently don't think that this is within the scope of what the plugin framework ought to deliver. There are more important things that need to get done first and if these are out of the way we might be able to dig this idea out again :)

Please keep the possibility that i can point the updater to a remote download URL for *.zip because on github I can't upload files of type *.mumble_plugin as release asset.<- tested, it does work

Great! That would have actually been a bummer because it would have invalidated my argument of using the naming convention in order to fix the confusion ^^

For this case, a manifest file would be even more useful to encode basic authorship and license information.

Yes indeed.

[hbeni]

There are more important things that need to get done first and if these are out of the way we might be able to dig this idea out again :)

Sure :)

However, as i envisioned it, we only would need one more "zip iteration" more to search for the "plugin binary package" (just one level of recursion, because of possible zip bombs). that should only be a few lines of code, but would safe me alot of work in the foreseable future (packaging and support)...

[Krzmbrzl]

Why is it a lot of work though? You have to bundle the plugin libraries together anyway so it seems that the only overhead is a single upload, isn't it? 👀

[hbeni]

The work will stem from the support requests, i fear…

[Krzmbrzl]

I think using the new file extension for the plugin archive should ease that 🤔

[Krzmbrzl]

To conclude: I think for the time being I will not allow the updater to be pointed to arbitrary zip files in order to not have to download unrelated files.
This might get reconsidered in the future but as of now this is not a priority and I am also not fully convinced that people won't start doing messy things if we are to allow for this 🤔

[hbeni]

Thanks for caring!

(but i think if people want to do messy things, they already can 😈 )