Dan, your points are valid. There’s a lot to consider when designing this plugin system. Perhaps a hybrid approach that uses Git for some things, wiki for others and functions added to the interval program to install, configure and delete plugins?
salbahra, good details about how Git can be used for plugins (I’m a Git noob).
One thing that makes these plugins tricky is the HTML pages, they have to go in the templates directory so you can’t just have one subdirectory under the plugins directory (ie plugins/autowater2000). The makeself tool can handle this with an auto-executed script, as Dan pointed out. But it’s trickier for version control systems, hence salbahra’s suggested workarounds.
Regarding this point, I suggest a naming convention for plugins so it is clear what files belong to what plugin. For example, if the plugin is SuperWater, all of its HTML files in the templates directory should use that name, ie SuperWater-config.html, SuperWater-status.html). In fact, perhaps they should be: “plugin-SuperWater-config.html” so it’s easy to know which HTML files are for the core interval program and which are for plugins. A standard naming convention would also make it easier to delete a plugin via the web interface and core interval code functions.