[libavg-devel] Plugin Interface Ideas

[Jan Bölsche]

Hi Nick,

your patch looks fine to me. I bet Uli will apply it soon.
A thought about updateDTD(): We could prevent updating too often by  
just setting a flag m_dirtyDTD which is checked right before any XML  
is actually parsed and then apply DTD modifications just in time.

Good work!
  Jan

On 05.11.2008, at 04:11, Nick Hebner wrote:

> 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
>
> < 
> generic_plugin_registration 
> .patch>_______________________________________________
> libavg-devel mailing list
> libavg-devel at datenhain.de
> https://mail.datenhain.de/mailman/listinfo/libavg-devel