[Ovmsdev] Plugin Repository
Derek Caudwell
d.caudwell at gmail.com
Wed Jul 15 05:04:58 HKT 2020
I had to have a few attempts to get he existing plugins working, so a
simple repo and install system would be great.
May be worth considering the following features from the Kodi addon repo
system:
- in the root folder there is a consistent name for initial script eg
plugin.js
- lib folder for including other scripts (could have web folder for html
elements)
- plugin folder tar/zipped for easy delivery and install
https://kodi.wiki/view/Add-on_structure
Cheers Derek
Date: Tue, 14 Jul 2020 13:45:55 +0200
> From: Michael Balzer <dexter at expeedo.de>
> To: ovmsdev at lists.openvehicles.com
> Subject: Re: [Ovmsdev] Plugin Repository
> Message-ID: <40cce917-3366-a6e5-1189-a28dc89578d3 at expeedo.de>
> Content-Type: text/plain; charset="utf-8"
>
> Mark,
>
> full ack, has been on my list as well. I'll handle the web UI side.
>
> 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?
>
> 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.
>
> 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.
>
> Currently there's a version on each element, and but we could/should
> simplify this to a central overall version for the plugin.
>
> To automatically install plugins, the meta data also needs to define the
> types and default setups for web/frontend plugins.
>
> Draft: edimax.json:
>
> {
> ? name: "edimax",
> ? title: "Edimax: Smart Plug Control",
> ? description: "Smart Plug control for Edimax models SP-1101W, SP-2101W
> et al",
> ? group: "Home Automation",
> ? info: "https://docs.openvehicles.com/en/latest/plugin/edimax/README.html
> ",
> ? maintainer: "Michael Balzer <dexter at dexters-web.de>",
> ? version: "2.1",
> ? prerequisites: ["ovms>=3.2.010"],
> ? elements: [{
> ??? type: "script",
> ??? path: "edimax.js",
> ??? name: "edimax" // optional, defaults to plugin name
> ? },{
> ??? type: "webpage",
> ??? path: "edimax.htm",
> ??? page: "/usr/edimax",
> ??? label: "Edimax Smart Plug",
> ??? menu: "Config",
> ??? auth: "Cookie"
> ? },{
> ??? type: "webhook",
> ??? path: "edimax-status.htm",
> ??? page: "/status",
> ??? hook: "body.post"
> ? }]
> }
>
> A method to easily disable/enable installed plugins would also be nice,
> i.e. as subcommands "plugin disable" / "plugin enable".
>
> Regards,
> Michael
>
>
> Am 14.07.20 um 07:55 schrieb Mark Webb-Johnson:
> >
> > 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.
> >
> > There are a couple of things I would like to now do:
> >
> > 1. Implement a mechanism for plugins to directly extend the console
> > command language (other than the current ?script exec PLUGIN.fn?).
> >
> > 2. 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 :-)
> >
> >
> > 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.
> >
> > However, #2 is a little more tricky and I?m looking for feedback on
> > the design of this. My idea is:
> >
> > * 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.
> >
> > * Each plugin has a unique name; the directory in /plugins.
> >
> > * 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:
> >
> > o Name: The plugin ID
> > o Title: One line title
> > o Group: Group for the plugin
> > o Version: The version string of the plugin
> > o Description: Longer textual description of the plugin
> > o Prerequisites: Prerequisites to be checked
> > (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)
> >
> > * We can automatically build the documentation, and list, for all
> > plugins for our docs.openvehicles.com
> > <http://docs.openvehicles.com>?(in a similar way to how it is done
> > for /plugin now).
> >
> > * 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.
> >
> > * On the module, we can store a list of repository servers (allowing
> > the user to add/remove as they require).
> >
> > * 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.
> >
> > * The ?plugin? command tree on the module will provide commands for:
> >
> > o List installed repositories
> > o Add a new repository
> > o Remove a repository
> > o List installed plugins
> > o List/Search available plugins
> > o Install a plugin
> > o Remove a plugin
> > o Update a plugin
> >
> > * 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).
> >
> >
> > Does that make sense? Any suggestions/comments?
> >
> > Regards, Mark.
> >
> >
> > _______________________________________________
> > OvmsDev mailing list
> > OvmsDev at lists.openvehicles.com
> > http://lists.openvehicles.com/mailman/listinfo/ovmsdev
>
> --
> Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal
> Fon 02333 / 833 5735 * Handy 0176 / 206 989 26
>
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <
> http://lists.openvehicles.com/pipermail/ovmsdev/attachments/20200714/87303d8f/attachment-0001.html
> >
>
> ------------------------------
>
> Message: 2
> Date: Tue, 14 Jul 2020 20:11:41 +0200
> From: Michael Balzer <dexter at expeedo.de>
> To: ovmsdev at lists.openvehicles.com
> Subject: [Ovmsdev] PSRAM fix in esp-idf release v3.3
> Message-ID: <34a88261-2f99-478b-20d6-6bdedb769fcd at expeedo.de>
> Content-Type: text/plain; charset="utf-8"
>
> Mark,
>
> it seems the fix has finally arrived in the official release 3.3 branch:
>
> https://github.com/espressif/esp-idf/issues/2892#issuecomment-658327913
>
>
> https://github.com/espressif/esp-idf/commit/f4333c8e3a554e8bb4210d825cbdf4bcaa1fc1b8
>
> Btw:
>
> > In the v3 silicon, the issue has been fixed, and the workaround is no
> > longer required.
> >
>
> I guess that means from some manufacturing point on we should provide
> two builds, one for the older hardware and one for the modules with v3
> chips, as the fix definitely has a performance impact.
>
> Regards,
> Michael
>
> --
> Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal
> Fon 02333 / 833 5735 * Handy 0176 / 206 989 26
>
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <
> http://lists.openvehicles.com/pipermail/ovmsdev/attachments/20200714/87809d0b/attachment.html
> >
>
> ------------------------------
>
> Subject: Digest Footer
>
> _______________________________________________
> OvmsDev mailing list
> OvmsDev at lists.openvehicles.com
> http://lists.openvehicles.com/mailman/listinfo/ovmsdev
>
>
> ------------------------------
>
> End of OvmsDev Digest, Vol 102, Issue 22
> ****************************************
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openvehicles.com/pipermail/ovmsdev/attachments/20200715/d3eab784/attachment-0001.html>
More information about the OvmsDev
mailing list