01-29-2016, 01:49 AM
(This post was last modified: 01-29-2016, 01:53 AM by LogicParrot.)
Important: Regardless of what is done, I think this should be planned very carefully and sestimatically. We don't want each plugin reinventing the wheel with its own update system, and we don't want to end up with fragmentation all over the place. It should be planned in such a way that even an inexperienced plugin developer can tap into the system.
Again, I think we should thoroughly discuss this and plan it very carefully before writing code. I would really like to help out here, both in code and planning.
I believe the new plugin website was done hastily. Firstly it did not implement categories, and secondly, it was created without plugin updaters in mind.
Perhaps an ideal system would have a website with a rest api, and a cuberite-sided plugin (or cpp code) which uses the API for update checking, and allows admins to browse for plugins right through the webadmin and install them with one click.
Again, I think we should thoroughly discuss this and plan it very carefully before writing code. I would really like to help out here, both in code and planning.
I believe the new plugin website was done hastily. Firstly it did not implement categories, and secondly, it was created without plugin updaters in mind.
Perhaps an ideal system would have a website with a rest api, and a cuberite-sided plugin (or cpp code) which uses the API for update checking, and allows admins to browse for plugins right through the webadmin and install them with one click.