Local Plugin Repo

[Schwertspize]

And there is no lua git implementing?

[Nether Mc]

I think about a mix of a plugin AND a standalone app (maybe in python or C++[Precompiled into .app, .exe and .deb]) to manage plugins. But with my Program needs a .txt file in the web to download information about the plugin locations, I don't think this should be done in a plugin, because it makes the server freezing while updating and downloading plugins.

[xoft]

You can't use luasocket for networking, you need to use our cNetwork-based classes, then it won't freeze the server.

[Nether Mc]

cNetwork seems very complicated! I'll try to write a plugin with it, but insn't there somnething like urllib in python(together with a subprocess class)? Anyway, I'll start developing a plugin to update plugins.

[Schwertspize]

Libgit2 ( https://libgit2.github.com ) has a lua variant ( https://github.com/libgit2/luagit2 ). It would be great if we can implement a plugin to initially DOWNLOAD plugins (=webadmin plugin Downloader which queries some sort of repo) through luagit2, then we can simply update them with luagit2 like with git pull.

[Nether Mc]

Seems cool, maybe do something together?

[xoft]

I still don't understand why you want to include Git so much. With the server's TCP link and TLS support, a plugin is perfectly capable of downloading any file from GitHub, as well as querying the GitHub API for any metadata. And best of all, it works asynchronously, so it doesn't freeze the server while processing.

[Nether Mc]

I'll host a plugin repository, which can be accessed over http, i think this would be the easiest way. The Plugin will download an index file wich contains information about the names, versions, authors and download paths of the plugins by using nID https://github.com/Myselfminer/nID (maybe 2.0, i'll write a lua port).

[xoft]

Sorry, but that sound unreasonably difficult and too dependent on a single person.

Consider this instead:
We create a github repository that will represent the plugin index. Each plugin that we want to add to the repository will get a single Lua file inside that repo with information such as the source location, author, description etc. For now, source location would have to point to another GitHub repo.
The plugin repository integration would query this GitHub repo regularly for updates about available plugins. For each plugin that the admin installs from this repository, the plugin would remember the metadata and regularly check the plugin's GitHub repo for updates, using the GitHub API. When a new version is detected, all the files get downloaded (again via GitHub API) and the plugin gets updated.

Anyway, all this would be much easier if Cuberite exports its HTTP client and server classes to the API, I think I'll start working on that today.

[bearbin]

I think it would be better if the description file is inside the plugin's own repository and not in a shared repo, and the shared repo only contains a list of other repos, which would be even less centralised. You might not even need a central repo, just pasting GH URLs into your plugin manager could work.