[gst-devel] GstObject API crufted?

[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.
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.

> - 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".

> - 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".

> - 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.

Hope that helps a bit.

Cheers,
Company