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 _______________________________________________ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers