What about thinking about Blender as about a system composed in the idea of different API joined together? It has been said during Bcon15 that an asset system needs its own api. This is drawing an idea to have Blender internally divided to different parts (bmesh, assets, depsgraph, etc) joined thru APIs which are a bit similar to modules mentioned here as 'plugins'. The whole Blender as a C-plugins conglomerate is a bit scary and graphic, but we have already some kind of that separation (I'm not very aware of Blender internals yet). Things done in a proper way could give us a nicer separation between different parts of the code, eliminate some spaghetti and old code and allow us to work on some parts without the fear of breaking things here and there. So I would opt for moving towards multicomponent system composed of smaller blackboxes instead of current partially monolithic system if we are going to 2.8 and speaking about C plugins will be easier when we will have nice Blender multicomponent design.
cheers pio Piotr Arlukowicz, BFCT *YT: /user/piotao?feature=guide* *FB:* */polskikursblendera* *TW:* */piotao* *Blender Network:* *https://www.blendernetwork.org/piotr-arlukowicz <https://www.blendernetwork.org/piotr-arlukowicz>* *Polski Kurs Blendera:* http://polskikursblendera.pl 2015-11-03 15:29 GMT+01:00 Gaia Clary <gaia.cl...@machinimatrix.org>: > 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 <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 > > _______________________________________________ > 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