[GnomeMeeting-devel-list] New video input api for pwlib: plugins!

[PUYDT Julien <julien puydt laposte net>]

Hi,

this is a follow-up to my previous posts on the topic.

I did write a first implementation, based on assumptions on the ability
of C++ to cope with dynamic typing; ie: I lost my time.

I took my chalk again, and got back to the design board; then
implemented what I came up with, successfully and fast.  (the sources
still need to be cleaned); that brings in:
* video input drivers come as plugins, ie: gm doesn't need to depend on
all of them and the libs they depend on;
* avc and dc will now have no problem living together;
* old programs will just work like they did, ie: it shouldn't have
broken the compatibility in any way;
* using the new feature is -- at least it was for gm -- easy.
it brings out:
* I wanted to have that plugin system parallel to the current one for
some time, then replace the old seamlessly: now I'm adding something.
That means the client sources have to be modified a little to make use
of it.

Now, let me describe how it works: I defined a PVideoInputManager class.
The programs use it to get a list of supported devices, then ask it to
provide with a PVideoInputDevice that supports a device.

Let me show how it works, with the example of the gm code I used to test
it:
*  gw->video_devices = PVideoInputManager::GetInputDeviceNames ();
we request the list of devices from the manager.
*  grabber = PVideoInputManager::GetOpenedDevice(video_device, FALSE);
the users asked to open video_device, we ask the manager to give us the
appropriate (already opened) PVideoInputDevice
* that's all: the rest hasn't changed (well, the druid will have to be
patched to do the same);

This is how it looks from the client perspective, now let's look at the
driver author's perspective: a driver in current pwlib is of the
PVideoInputDevice class, hence there is quite a few functions to write
for it. With my design, that is much the same thing:
* for the .h:
<#includes for pwlib>
<#includes for the libs used in the driver>
class PVideoInputMyPlugin: public PVideoInputDevice
{
 <declarations of the usual PVideoInputDevice functions>
 <declarations of the driver-specific functions>
};
==> no difference!
* for the .cxx:
extern "C" char *plugin_getname(void) { return "MYPLUGIN"; };

extern "C" PVideoInputDevice *plugin_create()
{
  return new PVideoInputMyPlugin();
}

extern "C" PStringList plugin_getdevices()
{
  return PVideoInputMyPlugin::GetInputDeviceNames();
}

<the class' functions definition, with the only notable difference that
if PVideoInputMyPlugin::GetInputDeviceNames detects "/dev/foo", it will
return "MYPLUGIN /dev/foo">
==> very little difference!

You then compile this driver with almost the same options as the rest of
pwlib, except:
* use -shared
* don't use -c
* add the -lfoo -lbar that are the library depends of your driver
* use -o myplugin.so instead of -o myplugin.o, as this won't get
compiled in the lib itself.

I guess the changes to the way the client programs and the driver
authors do things isn't that terrible.

Well, I guess I gave enough details for now, I'll answer to myself with
code, to discuss the API of the manager more in-depth, as I'm not sure I
got it right yes, and to discuss the implementation, as I know there are
things to fix in it.

Snark

PS: well, I almost said anything I had to say about the drivers, so
perhaps it is better that I say really all there is to say: the reason
why a driver reports "ME /dev/foo", is that if another driver sees the
same device and thinks it can use it too, then it will report "OTHER
/dev/foo", and the user will choose which he wants, and the manager will
know the difference. That is for example the case of /dev/raw1394 for
avc and dc.