[libavg-devel] Plugin Interface Ideas

[Nick Hebner]

On Wed, Nov 5, 2008 at 3:03 AM, Jan Bölsche <jan at muskelfisch.com> wrote:

> 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.


Ah of course! Such a simple solution, it's no wonder I couldn't come up with
it myself! :) Attached is an updated patch.

>
>
> 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
>
>
> _______________________________________________
> 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/20081105/4bf4c7c3/attachment-0001.htm 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: generic_plugin_registration.patch
Type: application/octet-stream
Size: 8646 bytes
Desc: not available
Url : http://mail.datenhain.de/pipermail/libavg-devel/attachments/20081105/4bf4c7c3/attachment-0001.obj