[gst-devel] registry changes

[David Schleef]

I finally checked in my registry changes.

The biggest user-visible change is that there is no longer a
gst-register command.  It is no longer needed, as the file it
created (registry.xml) is now autogenerated by libgstreamer.

The way things used to work with gst-register was a little bit
counterintuitive compared to compariable plugin or library
finding systems (like ld.so) -- you'd tell gst-register where
to find plugins, and it would generate the list and put it in
registry.xml.  Subsequent gstreamer apps would then use that
list.  The new system works more like ld.so -- you tell gstreamer
where to look for plugins (using an environment variable), and
it will look for plugins in those directories.  So basically,
the environment affects gstreamer directly, instead of going
though the intermediate gst-register.

Some new definitions (and rehashing old ones):

 - A "registry" (GstRegistry) is a list of plugins.  It is
   possible to have more than one in an app, but nearly all
   code will want to use the "default registry", which is the
   standard list of plugins that were found when libgstreamer
   was initialized.

 - A "plugin" (GstPlugin) is the internal representation of a
   plugin .so file on disk.  Plugins contain "features".  A
   plugin can either be loaded or unloaded.  It's also possible
   to have an internal plugin, one that doesn't represent a
   loadable module file.  This is used for features provided by
   libgstreamer itself (GstBin, etc.) as well as application
   features.  Plugins are nearly the same as 0.8.

 - A "feature" (GstFeature) is one of GstElementFactory,
   GstTypefindFactory, etc.  It contains information about a
   given element class or typefind function, and how to create
   or invoke it.  Nearly the same as 0.8.

Some important changes:

 - GstRegistryPools are gone.  I doubt anyone will notice.

 - Registries are no longer pluggable.  Since we only ever used
   one for as long as I remember, I don't think anyone will care.

 - The functions involved with loading plugins have been
   normalized.  The two primary functions are gst_plugin_load()
   and gst_feature_load().  The former will load a plugin, and
   the latter will load the plugin corresponding to the feature.
   A notable difference from 0.8 -- these functions return a new
   plugin or feature that represents the actual loaded plugin or
   feature.  In 0.8, GstPlugins were converted from unloaded to
   loaded state.  Now, the old plugin is deleted, and the new
   plugin replaces it.  I'm not entirely happy with this method,
   but it cures a bunch of potential threading problems.

Environment variables:

 - GST_PLUGIN_PATH: a colon-delimited list of directories to
   search for plugins.  Subdirectories are searched recursively.
   Defaults to nothing.

 - GST_PLUGIN_SYSTEM_PATH: same, but if set, will override the
   default system search list, which is 
   ${prefix}/gstreamer-0.9/plugins:${HOME}/.gstreamer-0.9/plugins.

 - GST_REGISTRY: The file that will be used for the registry cache
   file.  Defaults to ${HOME}/.gstreamer-0.9/registry.xml.

 It should be possible to completely replace
 --enable-plugin-builddir by setting GST_PLUGIN_SYSTEM_PATH to
 $(builddir)/gst.  The configure switch is still available for
 the near future.

Implementation details on the registry cache file:

 On initialization, libgstreamer searches the plugin directories
 for plugins.  When it finds a candidate .so (or .dll or .dynlib)
 file, it checks in the registry cache file to see if the 
 modification time and size match.  If they do not match, it loads
 the .so from disk and learns about the features inside.  If there
 is a match, it learns about the features from the cache.  At the
 end of initialization, if any plugins had to be loaded from disk,
 the new information is appended to the cache and written out.
 Cached information that didn't correspond to plugins in the
 search directories is minimally checked and if invalid, it is
 discarded.
  


dave...

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