[gst-devel] RFC: argument system?

[Erik Walthinsen]

The current gtk/glib get_arg/set_arg mechanism is functioning OK for us
right now, but I'm wondering if it will continue to do so.  Consider the
case of a mix matrix.  It'll have REQUEST pads for both input and output,
and internally it will have a volume level for each input channel going to
each output channel, or NxM volume knobs, like like an analogue mixer
board.

It is unclear to me whether gtk/glib arguments can be added/removed at
runtime, on a per-object basis.  It doesn't look likely, since the arg
data is stored in the Class structure.  Also, consider the naming scheme
for these arguments, not to mention the expense of doing string-matching
on each.

It makes me think that we may indeed want to build our own control system
for elements, but I'm hesitant to do that for quite a number of reasons.
First of all, the gtk/glib functions already exist, have a number of
features that are useful for more unusual plugins (see
http://gstreamer.net/lame-args.png for an example), and is still evolving
in glib 2.0.

Then again, we may want to consider that there are different classes of
controls for different classes of elements.  It could be that we use the
existing gtk/glib system for common arguments like those found in lame,
but our own system for things like mix levels, etc.  Basically anything
that could be changed frequently, even the existance of a given argument
is dynamic itself.

steveb's dynparms proposal may be the right way to go about this,
especially if it can be done efficiently and without significant code in
the common case (that is, less frequent changes that are still
time-critical).  If it's designed to be efficient at *both* dynamic
dimensions somehow, it would be ideal.

Comments?

      Erik Walthinsen <omega at temple-baptist.com> - System Administrator
        __
       /  \                GStreamer - The only way to stream!
      |    | M E G A        ***** http://gstreamer.net/ *****
      _\  /_