[libavg-devel] Plugin Interface Ideas

[Jan Bölsche]

Hi Nick,

thanks for your high quality feedback. We designed the plugin  
mechanism to address the special need of adding new custom node types  
to the system. The current solution seemed like the most straight  
forward approach of doing this.
What you suggest would indeed increase applicability and flexibility  
of the plugin mechanism and would require only very small changes.  It  
boils down to moving the registration code from PluginManager to each  
individual plugin. As a side-effect the plugin interface would be  
cleaner: the only exported function would be something like "void  
register()"
So -- if Uli agrees -- I don't see why we shouldn't move into that  
direction.

Uli and I agreed on the feature of unloading a previously loaded  
plugin being something You Ain't Gonna Need. It would be much like an  
unimport statement in Python. To implement this feature you'd have to  
cleanly undo the changes to the DTD and then run into the problem that  
the current node tree possibly does not validate against the DTD  
anymore. Too much hassle for too less of a feature.

Jan

On 03.11.2008, at 06:46, Nick Hebner wrote:

> Hello All,
>
> I was thinking of writing a plugin tonight using the shiny new  
> plugin interface (thanks Jan!), but ran into a roadblock with the  
> way that the plugin interface is currently designed. This experience  
> has got me thinking about how plugins will interact with the core  
> down the road, so I wanted to start a discussion about it.
>
> My idea for a plugin was to add a new camera subsystem based on a  
> seperate camera library. With the current plugin interface, this  
> would be possible by creating a new node type which exposes all of  
> the needed functionality. This functionality would of course be  
> almost identical the functionality currently provided by the  
> CameraNode. It would be great if instead of imlementing a new Node,  
> I could instead simply implement a new Camera object and make this  
> usable by the existing CameraNode.
>
> Another potential shortcoming of the current design is a plugin may  
> only export a single Node type. What if someone wanted to package a  
> number of nodes within a single plugin and have all of these nodes  
> registered when it is loaded.
>
> With these issues in mind, it seems to me that a more generic  
> loading procedure would be beneficial for plugin development in the  
> future. We could require generic plugin interaction event handlers  
> (for example onload(), onunload(), etc) to be exported, and allow a  
> plugin to define the behavior of these events. With this approach,  
> node plugins could register NodeDefinitions (as many as they want)  
> with the registry, and other types of plugins could do other things.  
> We would not assume that a plugin simply implements a single new Node.
>
> This generic approach lends itself to support for altering subsystem  
> implementations via plugins. For instance, say we wanted to use  
> DirectX to do our rendering, we could create a DisplayEngineRegistry  
> in the core that a DirectXDisplayEngine plugin could register with  
> in its onload(). Or in my case, I could register my new Camera type  
> with a CameraRegistry.
>
> I'm sure that these ideas are not new, and were probably considered  
> while designing the current plugin interface, but I just wanted to  
> start a dialog on the topic. So, anyone have any thoughts on this?  
> Discuss.
>
> Thanks,
>
> Nick
> _______________________________________________
> libavg-devel mailing list
> libavg-devel at datenhain.de
> https://mail.datenhain.de/mailman/listinfo/libavg-devel