<html>
  <head>
    <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
  </head>
  <body>
    Mark,<br>
    <br>
    full ack, has been on my list as well. I'll handle the web UI side.<br>
    <br>
    I don't think we need to migrate/change the folder structure, we
    should be able to just add the meta data. I tried to define the
    structure to be usable as a public repository. Did I miss something?<br>
    <br>
    Btw, I used the naming "module" plugins instead of "script" plugins,
    as web plugins also consist mostly of scripts. I thought that would
    clear things for users, but I'm not sure now.<br>
    <br>
    Regarding the plugin structure and meta data, we should decide
    wether to split plugins into their elements or keep them bundled.
    You seem to opt for bundles ("web subdirectory"). I would second
    that, but we then need to take into account a plugin may consist of
    multiple module and/or web plugins (see Edimax plugin for an
    example). Normally it's just one module plugin, but we should not
    restrict the system in that way. So the JSON file should allow to
    define an array of plugin elements / options.<br>
    <br>
    Currently there's a version on each element, and but we could/should
    simplify this to a central overall version for the plugin.<br>
    <br>
    To automatically install plugins, the meta data also needs to define
    the types and default setups for web/frontend plugins.<br>
    <br>
    Draft: edimax.json:<br>
    <br>
    <tt>{<br>
        name: "edimax",<br>
    </tt><tt><tt>  title: "Edimax: Smart Plug Control",<br>
          description: "Smart Plug control for Edimax models SP-1101W,
        SP-2101W et al",<br>
      </tt></tt><tt><tt>  group: "Home Automation",<br>
      </tt>  info:
      <a class="moz-txt-link-rfc2396E" href="https://docs.openvehicles.com/en/latest/plugin/edimax/README.html">"https://docs.openvehicles.com/en/latest/plugin/edimax/README.html"</a>,<br>
    </tt><tt><tt>  maintainer: "Michael Balzer
        <a class="moz-txt-link-rfc2396E" href="mailto:dexter@dexters-web.de"><dexter@dexters-web.de></a>",<br>
      </tt>  version: "2.1",<br>
        prerequisites: ["ovms>=3.2.010"],<br>
        elements: [{<br>
          type: "script",<br>
          path: "edimax.js",<br>
          name: "edimax" // optional, defaults to plugin name<br>
        },{<br>
          type: "webpage",<br>
          path: "edimax.htm",<br>
          page: "/usr/edimax",<br>
          label: "Edimax Smart Plug",<br>
          menu: "Config",<br>
          auth: "Cookie"<br>
        },{<br>
          type: "webhook",<br>
          path: "edimax-status.htm",<br>
          page: "/status",<br>
          hook: "body.post"<br>
        }]<br>
      }</tt><tt><tt><tt><tt><br>
            <br>
          </tt></tt></tt></tt>A method to easily disable/enable
    installed plugins would also be nice, i.e. as subcommands "plugin
    disable" / "plugin enable".<br>
    <br>
    Regards,<br>
    Michael<br>
    <tt><tt><tt><tt><br>
            <br>
          </tt></tt></tt></tt>
    <div class="moz-cite-prefix">Am 14.07.20 um 07:55 schrieb Mark
      Webb-Johnson:<br>
    </div>
    <blockquote type="cite"
      cite="mid:6BAA0DAB-6CD2-4E30-A868-6C54B1D40CC5@webb-johnson.net">
      <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=""
              moz-do-not-send="true">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>
      <br>
      <fieldset class="mimeAttachmentHeader"></fieldset>
      <pre class="moz-quote-pre" wrap="">_______________________________________________
OvmsDev mailing list
<a class="moz-txt-link-abbreviated" href="mailto:OvmsDev@lists.openvehicles.com">OvmsDev@lists.openvehicles.com</a>
<a class="moz-txt-link-freetext" href="http://lists.openvehicles.com/mailman/listinfo/ovmsdev">http://lists.openvehicles.com/mailman/listinfo/ovmsdev</a>
</pre>
    </blockquote>
    <br>
    <pre class="moz-signature" cols="72">-- 
Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal
Fon 02333 / 833 5735 * Handy 0176 / 206 989 26
</pre>
  </body>
</html>