History Page Raw
Overview

Artifact ID: 44a2f2ae3a7c88c40639eff71773a646e635c32dcd662c4767880b9fa44b193b
Page Name:References
Date: 2022-10-27 05:37:37
Original User: mario
Mimetype:text/x-markdown
Parent: 13150019a1669773dcf70fccb1fe8e8493af272830bd3d4c78146c8b95f9ced3 (diff)
Next b8b1a06a7f3281e48e2f9a05665aaaba41e95f4727c5b24e37b88ad844a9a61e
Content

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: pluginconf

  • Contained in this repo: dir/pluginconf/, API documentation: doc/tip/html/.
  • Comes with a full parser, and handles plugin activation with a simple configuration hashtable.
  • plugin_meta() can extract from files or loaded modules, and pyz archives

  • The admin UI sets a .plugins{} dict with activation states:

    "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 list.

  • Hooks/type: aren't utilized 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.

  • Started as streamtuner2 subproject, defines an extra arg: attribute for the config: list, now used by.

Powershell: Clicky

  • Has a full parser, and utilizes both config options and other meta fields at runtime..
  • type: covers a couple of magic values (init*,inline, cli, window, …) deciding on when to run/inline a script.
  • But primarily the category: is used for UI hookup (menu structuring). Which is one of the more basic uses for PMD.
  • Defines a bunch of custom fields like hidden:, nomenu:, vars: (like config struct), key: and shortcut:, which avoids lots of code duplication for plugins/scripts.
  • But there's no plugin activation states as such. All scripts are "loaded" all the time. Though there's a basic Plugin Manager now.

Ruby: cross package maker

  • Implements just a crude parser.
  • Uses PMD partially as source for packaging info. (Wasn't intended for that, but very applicable nonetheless!)
  • Defines the #pack: specifier for relative file references. Albeit partially supports #depends: specifiers.

PHP: libconfig / Generic PHP Plugins

  • Was the original implementation. Still pretty close to the current spec.
  • Except that 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