[Bf-committers] Some Ideas for a Blender Plugin System

[Martin Felke]

Hi, today i wrote down a couple of more thoughts regarding a plugin
system. As said earlier, those serve only as discussion starting points
and are not meant yet as design principles made out of cement. :)

Fat VS Slim Core
----------------
- currently we have a fat core which contains all functionality 
  as monolith
- hard to extend and to maintain because it might be everything depends 
  on everything else
- idea: a slim, "bootloader like" core, which handles modules and 
  plugins registration and deregistration and serves as API Hub (of 
  existing modules)
- modules are not standalone, they communicate via a central core API 
  Hub so they need the core as well
- this way the core can track module APIs and provide a fallback (as 
  in exception handler) for missing code / functions (if module or
  plugin is not present)

Modules VS Plugins
------------------
- need to distinguish between logical code separation (module) and 
  "physical" separation (plugin, as in shared library or dll)
- group existing core functionality to modules (like, an editor could 
  be a module, or even a modifier)
- base modules can be provided by "base" plugins, and extension modules 
  by external plugins
- plugins can provide parts of modules, entire modules or multiple 
  modules (like nodes maybe, modifiers, new editors, or extensions to 
  editors)

Dependencies
------------
- do we want to have inter-plugin dependencies ? For a slim core 
  approach this might be necessary, if plugin A provides a module or 
  part where plugin B 's code depends on
- else base modules should be moved / kept in the core, so everyone has 
  a minimum set of functionality without needing to use plugins
- but in general, should plugin code only use Core API (the Hub ?) 
  would be better than "directly" accessing other plugins code, because 
  the core might provide the error fallback in case a plugin isnt 
  present

Plugin properties
-----------------
- should be "hotpluggable", addable, removable during runtime
- core needs to take care of disabling all related functionality when 
  module is unloaded (closing editor, saving for example)
- each plugin needs an unique identifier of some kind, and versioning 
  info
- if basis modules are in a plugin, this plugin needs to be flagged as 
  important or official or so
- plugins could be classified by their purpose, like provides Module X, 
  extends Module Y, replaces Module Z, removes Module W