Hi, I'm missing the main point here which would be, what is the advantage of a C/C++ plugin system over the current Python addon interface?
I'm currently developing an addon which relies on an external C++ SDK. I got things working with ctypes and C API. It works pretty fine. Cheers, Dalai -- blendernetwork.org/dalai-felinto www.dalaifelinto.com 2015-11-03 10:59 GMT-02:00 Martin Felke <martin.fe...@t-online.de>: > 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 _______________________________________________ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers