
<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body dir="auto">This sounds great! Would really ease up the installation process and allow less experienced users to add the additional features.<br><br><div dir="ltr"><p class="MsoNormal" style="margin: 0cm 0cm 0.0001pt;">Regards,</p><p class="MsoNormal" style="margin: 0cm 0cm 0.0001pt;"><b><span lang="EN-US" style="background-color: rgba(255, 255, 255, 0);">Jaunius Kapkan </span></b><i style="background-color: rgba(255, 255, 255, 0);">[Sent from cellphone]</i></p></div><div dir="ltr"><br><blockquote type="cite">On 2020-07-14, at 08:57, Mark Webb-Johnson <mark@webb-johnson.net> wrote:<br><br></blockquote></div><blockquote type="cite"><div dir="ltr"><meta http-equiv="Content-Type" content="text/html; charset=utf-8"><div class=""><br class=""></div><div class="">I feel that our plugin system offers a missed opportunity. By making small extensions to available functionality, we can use this system to do so much - and with a much lower complexity and barrier to entry compared to C++ ESP IDF development.</div><div class=""><br class=""></div><div class="">There are a couple of things I would like to now do:</div><div class=""><br class=""></div><div class=""><ol class="MailOutline"><li class="">Implement a mechanism for plugins to directly extend the console command language (other than the current ’script exec PLUGIN.fn’).<br class=""><br class=""></li><li class="">Implement a plugin repository, and command line tools for managing plugins. We simply need to have a store and directory of available plugins, a way of searching/listing those, and a uniform way to install/remove plugins. Once this is done, perhaps someone can handle the web UI side of this, and perhaps that can even be done as a plugin :-)</li></ol></div><div class=""><br class=""></div><div class="">I’m already working on #1. Just an extension to the existing script system to allow plugins to register commands, and to have the command register/deregister done automatically on plugin load/unload.</div><div class=""><br class=""></div><div class="">However, #2 is a little more tricky and I’m looking for feedback on the design of this. My idea is:</div><div class=""><br class=""></div><div class=""><ul class="MailOutline"><li class="">Store the plugins in a new github/openvehicles/Open-Vehicle-Monitoring-System-3/plugins folder. Eventually the /plugin folder will all be migrated to here.<br class=""><br class=""></li><li class="">Each plugin has a unique name; the directory in /plugins.<br class=""><br class=""></li><li class="">Within each plugin directory, there is a <name>.json file (JSON format) with defined tags to describe the plugin. If the plugin delivers a web extension, that is in the ‘web’ subdirectory. If the plugin delivered a script extension, that is in the ’script’ directory. Documentation (in rst format) is in the ‘docs' directory. The JSON file would need the following, at a minimum:<br class=""><br class=""></li><ul class=""><li class="">Name: The plugin ID</li><li class="">Title: One line title</li><li class="">Group: Group for the plugin</li><li class="">Version: The version string of the plugin</li><li class="">Description: Longer textual description of the plugin</li><li class="">Prerequisites: Prerequisites to be checked<br class="">(Each plugin installed provides name=version, the system provides system-level ones such as the version of firmware, and then the prerequisites is simple a list of <name><operator><version> as required)<br class=""><br class=""></li></ul><li class="">We can automatically build the documentation, and list, for all plugins for our <a href="http://docs.openvehicles.com" class="">docs.openvehicles.com</a> (in a similar way to how it is done for /plugin now).<br class=""><br class=""></li><li class="">On a repository server, as part of a nightly build job, we can automatically build a single directory JSON file from the <name>,json descriptors. We can publish this, as well as a git export/checkout of the plugins, on a http download site.<br class=""><br class=""></li><li class="">On the module, we can store a list of repository servers (allowing the user to add/remove as they require).<br class=""><br class=""></li><li class="">Contributors/authors of plugins simply GitHub clone our repository, and issue pull requests as appropriate. They can also have their own private repository servers (just need to host the directory json file and associated code files) and add it to their modules.<br class=""><br class=""></li><li class="">The ‘plugin’ command tree on the module will provide commands for:<br class=""><br class=""></li><ul class=""><li class="">List installed repositories</li><li class="">Add a new repository</li><li class="">Remove a repository</li><li class="">List installed plugins</li><li class="">List/Search available plugins</li><li class="">Install a plugin</li><li class="">Remove a plugin</li><li class="">Update a plugin<br class=""><br class=""></li></ul><li class="">I would like to try to unify the web and script plugin systems a bit more closely. They are really two sides of the same coin (with some plugins providing both).</li></ul></div><div class=""><br class=""></div><div class="">Does that make sense? Any suggestions/comments?</div><div class=""><br class=""></div><div class="">Regards, Mark.</div><div class=""><br class=""></div><span>_______________________________________________</span><br><span>OvmsDev mailing list</span><br><span>OvmsDev@lists.openvehicles.com</span><br><span>http://lists.openvehicles.com/mailman/listinfo/ovmsdev</span><br></div></blockquote></body></html>