One of the benefits of a Blender PLugin System (bps) that i can think of is: The Collada module could be extracted into a separate plugin.
But this can only work well if the bps does not force us to rebuild a plugin for each blender release. Otherwise maintenance would become a nightmare, especially because plugins need to be built for multiple platforms. cheers, Gaia On 03.11.2015 14:14, Dalai Felinto wrote: > 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 <[email protected]>: >> 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 >> [email protected] >> http://lists.blender.org/mailman/listinfo/bf-committers > _______________________________________________ > Bf-committers mailing list > [email protected] > http://lists.blender.org/mailman/listinfo/bf-committers _______________________________________________ Bf-committers mailing list [email protected] http://lists.blender.org/mailman/listinfo/bf-committers
