[libavg-devel] Subsystem Plugins

[Ulrich von Zadow]

Hi Nick,

we implemented node plugins to allow for project-specific node types.  
For instance, we're using the plugins right now to add  a fluid  
dynamics node for a wind channel simulation. This node wouldn't make  
sense in generic libavg because it renders stuff that makes little  
sense outside of that specific project.

With that in mind: I'm not convinced that we need a plugin system for  
cameras. Where is the benefit over just implementing new camera  
classes and integrating them into the libavg core? OTOH: Camera  
support for windows other than DirectShow  would be great. In  
particular, the CMU 1394 software looks good at first sight because  
it's standards-based and doesn't require additional libraries and  
exposes lots of camera features.

Cheers,

   Uli

On Nov 9, 2008, at 7:25 PM, Nick Hebner wrote:

> Hey All,
>
> As I mentioned in an earlier email, I had some interest in writing a  
> plugin that implemented a new camera subsystem. Well with the new  
> generic plugin registration code in place and a few more changes, I  
> have been able to do just that. Attached is a patch adding a  
> SubsystemManager class that can be used to register and build  
> subsystem instances. Currently the only subsystem that this class  
> manages is cameras, but I just wanted to get something working on a  
> basic level before attempting anything too complicated. In designing  
> this functionality, I made a few assumptions.
>
> 1. There are a small number of subsystems that this class will  
> manage (e.g. DisplayEngine, AudioEngine, Camera, etc).
> 2. Different subsystem types require wildly different initialization  
> information.
> 3. Similar subsystem types require basically the same initialization  
> information.
>
> Based on these assumptions, I decided that the registration and  
> creation functions should be per-subsystem-type. I do not see any  
> merit in providing a single createSubsystem() and having all  
> subsystems implement a Subsystem interface. They are all handled too  
> differently to do so. Instead, I envision a register and create  
> function for each subsystem type.
>
> Registration functions will take a subsystem name and builder  
> function. The builder function will take initialization parameters  
> common to that subsystem type and return a pointer to an instance of  
> that subsystem.
>
> Create functions will take a subsystem name and the parameters to  
> pass the registered builder function.
>
> Because the number of subsystems is small and the parameters to a  
> subsystem are fixed, I do not see a need for the complicated Arg  
> passing mechanisms that are required by Nodes.
>
> I have updated the Windows build distribution with the example  
> camera subsystem plugins that I have developed (one using the CMU  
> 1394 driver, the other using the VideoWrapper library, you will need  
> to download these of course). This patch does not represent a  
> complete implementation of this idea, I just wanted to get some  
> thoughts on this. So, what do you think?
>
> Thanks,
>
> Nick  
> < 
> subsystem_plugin.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