#### 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: →

 * Is now contained in this repository:
 * Comes with a full parser, and handles plugin activation with a simple configuration hashtable.
 * 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.
 * Defines an [extra `arg:` for the `config:` list.

## Powershell:

 * Has a [full 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 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

 * Implements just a [crude
 * 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

 * 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