[libavg-devel] Subsystem Plugins

[Nick Hebner]

Well, my main reason for moving toward a pluggable camera subsystem is a
perceived resistance to incorporating too much Windows support into the
core. With this model, it is up to a libavg distributor to include
subsystems relevant to the target platform. It also frees you the maintainer
from having to maintain the code that could be implemented in a 3rd party
plugin. In addition, it allows you to peacefully disagree with the choice of
camera subsystem made by a 3rd party. For instance, you mentioned that the
CMU driver looks good, but you might not be so thrilled with VideoWrapper.
Well if camera plugins are not possible and you are not interested in
supporting this library, then my only option is to hack the core, and create
a new libavg branch that still is not officially supported and is difficult
to keep up to date.

If my perception is not valid, and there is willingness to add new
Windows-only code into the core, then great, we can do that.

I think that a project like this caters mainly to people who are working in
unique environments and interacting with various devices, and I think that
providing a way to easily extend all aspects of the library is a good thing.

Thanks,

Nick

On Sun, Nov 9, 2008 at 1:07 PM, Ulrich von Zadow <uzadow at libavg.de> wrote:

> 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
>
>
>
>
> _______________________________________________
> 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/20081109/596e01c9/attachment-0001.htm