[gst-devel] about base classes

Ronald S. Bultje rbultje at ronald.bitfreak.net
Fri Mar 18 06:53:17 CET 2005

Hi Benjamin,

On Tue, 2005-03-08 at 20:54, Benjamin Otte wrote:
> Given this as the basic constraint, base classes should be slowly built on
> top of each other where possible. So if you have two different sets of
> functionalities that can be seperated, do it. (A general sink and an audio
> sink class may or may not be such cases.)

That's good, so far.

> Given this, an audio sink base class to me still looks like it would
> provide these functions:
> /* try to open device */
> gboolean  (* open)        (GstAudioSink *sink);
> /* close device */
> void      (* close)       (GstAudioSink *sink);
> /* get possibly supported formats from device */
> GstCaps * (* get_formats) (GstAudioSink *sink);
> /* try to set given format */
> gboolean  (* set_format)  (GstAudioSink *sink, const GstCaps *caps);
> Or did I miss something?
> > 2c - audio sink implementation
> >  * format negotiation, backend setup.
> >  Because this cannot easily be generalized without generalizing
> >  too much, or we don't gain anything by generalizing it.

Basically that part.

It's not like your proposed setup is wrong and mine is right, or the
other way around. Both are equally valid and make perfect sense. Now,
the reason that I decided not to add backend setup (open/close) and
format negotiation (get_format, set_format, ...) to the base class is
because it doesn't gain us anything. It requires us to abstract
something away without any gain (we can discuss more about this gain vs.
no gain thing if you wish; this is only an opinion, not a fact). It's
not like it's a lot of extra code (if any). The reason that I don't do
it is much simpler: we're distracting the programmer from the main
GStreamer plugin/element API for no good reason.

Again, both are equally valid and correct. I just decided not to for the
above reason. You guys may actually all prefer to go with including it
in the base class anyway, and I can live with that as well.


Ronald S. Bultje <rbultje at ronald.bitfreak.net>

More information about the gstreamer-devel mailing list