[libavg-devel] Plugin Interface Ideas

[Ulrich von Zadow]

Hi,

all this sounds very good :-).

I'll have a look at the patch over the weekend and probably apply it.  
I'll also probably apply Nick's other patch - the one that changes the  
windows plugin suffix to .dll and changes the path delimiter to ; on  
windows so C:\ and similar stuff gets parsed correctly - then.

Cheers,

   Uli

On Nov 5, 2008, at 12:03 PM, Jan Bölsche 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.
>
> 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
>

--
Any technology distinguishable from magic is insufficiently advanced.

Ulrich von Zadow | +49-172-7872715
Jabber: coder at c-base.org
Skype: uzadow