D 2018-07-06T19:49:48.922 L References N text/x-markdown U mario W 2599 #### References / Existing Implementations PMD is somewhat cemented now for most of my projects. Even if you don't actually need the management features. This is just a list of existing parsers and usage schemes. ## Python: [streamtuner2](http://fossil.include-once.org/streamtuner2/) → [pluginconf](https://pypi.org/project/pluginconf/) * Comes with a full parser, and handles plugin activation with a simple configuration hashtable. * [plugin_meta()](http://fossil.include-once.org/streamtuner2/artifact/8ae013bd9365f11be08fe429caf0a7f2e18976cc) can extract from files or loaded modules, and pyz archives * The admin UI sets conf.plugins{} for activcation states as follows: "plugins": { "bookmarks": true, "cachereset": false, "configwin": true, "continuous_record": false, "delicast": true, * Plugins are scanned for meta infos on each startup (there isn't too many), and instantiated according to config table. * Hooks/`type:` are not used much. Instead class types are used implicitly, or plugins register themselves with the main application. * `config:` options show up in a neat combined settings window, defaults are applied on startup / to the conf{} dict. ## Powershell: [Clicky](http://fossil.include-once.org/clickycoloury/) * Albeit has a [full parser](http://fossil.include-once.org/clickycoloury/artifact/fb2017bd6797bf6c2c9df6c92966632c7262cb61), only the config options are fully used. * `type:` covers a few magic values (init*, inline, cli, …) * But primarily the `category:` is used for UI hookup (menu structuring). Which is one of the more basic uses for plugin meta data. * There's no plugin activation states as such, all scripts are "loaded" all the time. * Albeit there's a basic Plugin Manager now. ## Ruby: [cross packaage maker](http://fossil.include-once.org/xpm/) * Implements just a [crude parser](http://fossil.include-once.org/xpm/artifact/35d5f731ae94db88356bd05042812970781261d0). * Uses PMD partially as source for packaging info. (Wasn't intended for that, but very convenient!) * Defines the `#pack:` specifier for relative file references. Albeit partially supports `#depends:` specifiers. ## PHP: [libconfig / Generic PHP Plugins][http://milki.include-once.org/genericplugins/) * Was the original implementation. Still pretty close to the current spec. * Only the `config:` syntax uses HTML-style rather than JSOL attributes. * Main goal here was a *non-destructive `config.php` editing* feature via plugin meta data. Z a33c940adf21f89b0bb7a24440eb0c0e