Date: Tue, 14 Jul 2020 13:45:55 +0200
From: Michael Balzer <dexter@expeedo.de>
To: ovmsdev@lists.openvehicles.com
Subject: Re: [Ovmsdev] Plugin Repository
Message-ID: <40cce917-3366-a6e5-1189-a28dc89578d3@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@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@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@expeedo.de>
To: ovmsdev@lists.openvehicles.com
Subject: [Ovmsdev] PSRAM fix in esp-idf release v3.3
Message-ID: <34a88261-2f99-478b-20d6-6bdedb769fcd@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@lists.openvehicles.com
http://lists.openvehicles.com/mailman/listinfo/ovmsdev


------------------------------

End of OvmsDev Digest, Vol 102, Issue 22
****************************************