[gst-devel] Why wrapping GLib interfaces?

[Ronald Bultje]

Hi Ramon,

On Mon, 2003-10-13 at 13:06, Ramón García wrote:
> You suggest that it is necessary to offer the
> functionality of deciding inside each different object
> whether to expose an interface or not.
> 
> Can you post a use case that shows that this is
> useful?

The OSS specs define that a sound card does not necessarily expose a
mixer. Professional soundcards have hardware mixers. See the 'Note' box
on page 18 of the OSS programming guide, available from
http://www.opensound.com/.

This means that for an object that wraps oss, like osselement, the
question of having a mixer can only be defined at runtime, so you need
to ask the element for whether it implements the mixer interface for
this specific instance or not.

There are more ways to do this. You could make a flag for this that's a
property on the element, but that way, you require another API type
(properties) for the mixer interface, which (imo) is ugly.
A second option is that you make a virtual function in the mixer
interface that queries for whether this is supported or not. Another
option looks like this: you add another interface, required by the mixer
interface, that does this. The nice thing is that this prevents code
duplication if you need this supported thing in more than one interface.
Also, it will not mess up the interface API yourself. I chose for this,
mostly because it allows me to wrap the typecast-macro from element to
interface-type inside this supported-virtual function. Consequently, I
can do casts (GstMixer *mixer = GST_MIXER (element)) which return NULL
if this specific instance doesn't implement the interface, or I can do
casts checks (if (GST_IS_MIXER (element) { .. }) to query for this,
which make this look extremely elegant. It works exactly as the rest of
GObject, but with an integrated, automatic implementation-check.

The name GstInterface, as Benjamin has said before, is probably wrong.
It should be called GstInstanceSupportsInterface or
GstElementSupportsInterface.

> Thus the class
> of that object can have a function Interface*
> getInterface() to get an instance of that interface,
> which can return NULL. That should be different than
> implementing an interface.

This is basically what we do, but a bit more elegant: the application
doesn't actually have to query; instead, it's done automatically inside
the cast or cast-check.

Ronald

-- 
Ronald Bultje <rbultje at ronald.bitfreak.net>
Linux Video/Multimedia developer