[libavg-devel] Plugin Interface Ideas

Sat Nov 8 19:45:31 CET 2008

Oops, sorry about that. Thanks though!

Nick

On Sat, Nov 8, 2008 at 10:39 AM, Ulrich von Zadow <uzadow at libavg.de> wrote:

> I've applied the patch - after (ahem) removing all the tab characters
> in it.
>
> Thanks a lot,
>
>   Uli
>
> On Nov 6, 2008, at 4:10 AM, Nick Hebner wrote:
> >
> > 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
> >
> > <
> > generic_plugin_registration
> > .patch>_______________________________________________
> > libavg-devel mailing list
> > libavg-devel at datenhain.de
> > https://mail.datenhain.de/mailman/listinfo/libavg-devel
>
> --
> Any technology distinguishable from magic is insufficiently advanced.
>
> Ulrich von Zadow | +49-172-7872715
> Jabber: coder at c-base.org
> Skype: uzadow
>
>
>
>
> _______________________________________________
> 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/20081108/72139bf7/attachment.htm 