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

[Gaia Clary]

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