[gst-devel] more registry info

[David S. <ds...@sc...>]

I've reached a bit of an impasse with refcounting in the
registry/plugin/feature objects.  It mostly works, except one
horrid API feature is exposed to the user, which I didn't intend
or forsee.  That API feature is that if you want to hold on to
a GstPluginFeature, you reference its plugin, not the feature
itself.

The reason for this is much clearer in the diagrams I attached.
In the current refcounting method, the registry holds references
on plugins, and plugins on features.  This is roughly an extension
of how 0.8 works.  Problem is, features rely on plugins, because
GstPlugin contains the information on how to load a feature.  So
if your app holds on to a list of features, and ref the features,
the plugins might disappear.  The solution is for plugins to hold
weak references on features, and features to ref plugins.  But
weak references and threading make things more complicated.

My analysis of what really is going on is in the second picture.
Registries only care about the list of features in a plugin, and
features only care about the plugin name/filename (so it can figure
out how to load the thing.)  So it makes sense conceptually to
split GstPlugin into these separate parts.

However, once doing this, one realizes that we now just have a
list of lists in the registry and feature lists, and since apps
seldom care about which plugin a feature is in, it seems silly to
have this arbitrary separation -- why not just a long list of
features in some database structure that makes it easy to look
up features in the way that apps prefer (like separated by type
and in rank order.)

Once I discovered this, I realized that making this change would
simplify the API for apps manipulating features.  It also gets
rid of a lot of code duplication between plugin and feature code.
So I think this is the way to go.

Oh yeah -- a few justifications for the uninitiated.  We need to
handle the case where plugins/features appear/disappear from a
running process.  Up until now, I only cared about plugins that
changed before they were loaded, but now I realize that features
can change *in the loaded state*, particularly if the features
are handled by another loading/unloading system, such as libvisual
or (in a roundabout way) Python.  Even without these arguments,
I think the changes make sense, though.



dave...

-- 
David Schleef
Big Kitten LLC (http://www.bigkitten.com/) -- data acquisition on Linux