[gst-devel] GstObject API crufted?

[Martin Schulze]

Am 04.04.2003 21:31 schrieb(en) Benjamin Otte:
> Ok, I'll try to answer as good as I can, please correct me if I tell
> something wrong.
> 
> On Thu, 3 Apr 2003, Martin Schulze wrote:
> > - GstObject has a data field "parent". This field seems to be used only
> >    for GstElement and GstPad. Other structures don't seem to have a
> >    clear container<->child relationship. Is this right?
> >
> You're missing at least clocks and schedulers. Clocks usually belong to
> an
> element (or a scheduler - I don't know about clocks, but they belong
> somehere) and schedulers belong to their base element. So it makes sence
> there.

Clocks are referenced by elements and schedulers equally. And it looks like
they are shared between different elements/schedulers so they don't seem to
have a parent. Maybe I'm missig something.

> I'm not aware of any subclass where it does not make sence to have a
> parent field. Those should probably be fixed to descend from GObject.

The parent field is not used anywhere but in GstPad and GstElement.
Running 'grep "gst_.*_set_parent" gst/*.c' will show you what I mean.

However, I don't know whether it might become useful for clocks,
schedulers and the other types to have a parent field at some point;
so I'm not the one to judge what other types should inherit from
GObject rather than GstObject. I think someone with a deeper insight
should have a close look at this before some stable branch is based
on gstreamer-0.7.

> > - There is a function gst_object_destroy() that forces the destruction
> >    of the passed object. Is this intended to work at any time? For
> >    GstElement/GstPad? For other types? Is the parent notified about
> >    the destruction?
> >
> I think this is cruft left over from the glib/gtk 1.2 days. After a
> little
> grepping it's only used in old examples and test. So I vote for "remove
> it, we're properly refcounting".

Yes, I totally agree.

> > - Objects of type GstObject can be in floated state. Is this useful for
> >    all derivations of GstObject?
> >
> I think it's useful for every object that can have a parent. So the
> obvious answer would be "yes".

Again, the parent field is only used by GstPad and GstElement :-)

> > - Is it useful for all structs that currently inherit GstObject to have
> the
> >    data fields "name" and "lock"?
> >
> I'm not sure if we have a _get_scheduler_by_name function and if it would
> make sense there, but IMO it makes sense for the rest of objects I can
> think of, because they can all appear in greater numbers and a
> _get_by_name is useful.
> I don't know what locks are used for.

Running "grep GST_LOCK gst/*.c" it lock like locks are used for clocks
and elements.

Cheers,

   Martin