[libavg-devel] Plugin Interface Ideas

[Nick Hebner]

Hi Jan,

The plugin unloading stuff you mention makes sense, and I agree is not
really worth it, so we will require just a register function. I have coded
this up and attached a patch for the core as well as the ColorNode plugin.

In moving registration from the PluginManager to the plugin, I realized that
it was taking a lot of code in the plugin to get itself registered because
the parent node updates are somewhat klunky. Since every single Node plugin
will have to reproduce these steps, I decided that this logic should be
moved into the core. Now a plugin can register itself with one function call
by providing its NodeDefinition and parent node names to
Player::registerNodeType(). The parent node names argument defaults to NULL
and is ignored for all core node types since node relationships are defined
child-wise in the core.

This change makes Player::updateNodeDefinition() unneccessary as far as I
can tell because the only update to a NodeDefinition that you would likely
wish to make is to add children, right?

The only other thing that a plugin will have to do is call
Player::updateDTD(). A call to this could be added to
Player::registerNodeType() to get rid of this requirement, but then we would
update the DTD 12 times when Player is constructed. This also allows plugins
to register multiple plugins before forcing a DTD update.

So anyway, take a look at the patch and let me know what you think or if I
missed anything.

Thanks,

Nick

On Mon, Nov 3, 2008 at 2:38 AM, Jan Bölsche <jan at muskelfisch.com> wrote:

> 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
>
>
> _______________________________________________
> libavg-devel mailing list
> libavg-devel at datenhain.de
> https://mail.datenhain.de/mailman/listinfo/libavg-devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.datenhain.de/pipermail/libavg-devel/attachments/20081104/c5da878f/attachment.htm 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: generic_plugin_registration.patch
Type: application/octet-stream
Size: 7490 bytes
Desc: not available
Url : http://mail.datenhain.de/pipermail/libavg-devel/attachments/20081104/c5da878f/attachment.obj