mirrors/gstreamer
mirrors/gstreamer
1
1
Fork 0
mirror of https://gitlab.freedesktop.org/gstreamer/gstreamer.git synced 2024-11-26 19:51:11 +00:00
Code Issues 1 Projects Releases Wiki Activity

gst/gstregistry.c: Move big documentation comment into class section header, so that it appears in the API docs.

Browse source 
Original commit message from CVS:
* gst/gstregistry.c:
Move big documentation comment into class section header, so that it
appears in the API docs.
This commit is contained in:
Stefan Kost 2006-07-26 20:30:55 +00:00
parent d5b1c52899
commit 4e6ddbfc50
2 changed files with 63 additions and 52 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

6
ChangeLog
View file

@ -1,3 +1,9 @@
2006-07-26 Stefan Kost <ensonic@users.sf.net>
* gst/gstregistry.c:
Move big documentation comment into class section header, so that it
appears in the API docs.
2006-07-26 Jan Schmidt <thaytan@mad.scientist.com> 2006-07-26 Jan Schmidt <thaytan@mad.scientist.com>
* docs/gst/gstreamer-sections.txt: * docs/gst/gstreamer-sections.txt:

109
gst/gstregistry.c
View file

@ -28,6 +28,63 @@
* *
* One registry holds the metadata of a set of plugins. * One registry holds the metadata of a set of plugins.
* All registries build the #GstRegistryPool. * All registries build the #GstRegistryPool.
*
* <emphasis role="bold">Design:</emphasis>
*
* The #GstRegistry object is a list of plugins and some functions for dealing
* with them. #GstPlugins are matched 1-1 with a file on disk, and may or may
* not be loaded at a given time. There may be multiple #GstRegistry objects,
* but the "default registry" is the only object that has any meaning to the
* core.
*
* The registry.xml file is actually a cache of plugin information. This is
* unlike versions prior to 0.10, where the registry file was the primary source
* of plugin information, and was created by the gst-register command.
*
* The primary source, at all times, of plugin information is each plugin file
* itself. Thus, if an application wants information about a particular plugin,
* or wants to search for a feature that satisfies given criteria, the primary
* means of doing so is to load every plugin and look at the resulting
* information that is gathered in the default registry. Clearly, this is a time
* consuming process, so we cache information in the registry.xml file.
*
* On startup, plugins are searched for in the plugin search path. This path can
* be set directly using the %GST_PLUGIN_PATH environment variable. The registry
* file is loaded from ~/.gstreamer-$GST_MAJORMINOR/registry-$ARCH.xml or the
* file listed in the %GST_REGISTRY env var. The only reason to change the
* registry location is for testing.
*
* For each plugin that is found in the plugin search path, there could be 3
* possibilities for cached information:
* <itemizedlist>
* <listitem>
* <para>the cache may not contain information about a given file.</para>
* </listitem>
* <listitem>
* <para>the cache may have stale information.</para>
* </listitem>
* <listitem>
* <para>the cache may have current information.</para>
* </listitem>
* </itemizedlist>
*
* In the first two cases, the plugin is loaded and the cache updated. In
* addition to these cases, the cache may have entries for plugins that are not
* relevant to the current process. These are marked as not available to the
* current process. If the cache is updated for whatever reason, it is marked
* dirty.
*
* A dirty cache is written out at the end of initialization. Each entry is
* checked to make sure the information is minimally valid. If not, the entry is
* simply dropped.
*
* <emphasis role="bold">Implementation notes:</emphasis>
*
* The "cache" and "default registry" are different concepts and can represent
* different sets of plugins. For various reasons, at init time, the cache is
* stored in the default registry, and plugins not relevant to the current
* process are marked with the %GST_PLUGIN_FLAG_CACHED bit. These plugins are
* removed at the end of intitialization.
*/ */
#ifdef HAVE_CONFIG_H #ifdef HAVE_CONFIG_H
@ -57,58 +114,6 @@
static GStaticMutex _gst_registry_mutex = G_STATIC_MUTEX_INIT; static GStaticMutex _gst_registry_mutex = G_STATIC_MUTEX_INIT;
static GstRegistry *_gst_registry_default = NULL; static GstRegistry *_gst_registry_default = NULL;
/*
* Design:
*
* The GstRegistry object is a list of plugins and some functions for dealing
* with them. Plugins are matched 1-1 with a file on disk, and may or may not be
* loaded at a given time. There may be multiple GstRegistry objects, but the
* "default registry" is the only object that has any meaning to the core.
*
* The registry.xml file is actually a cache of plugin information. This is
* unlike versions prior to 0.10, where the registry file was the primary source
* of plugin information, and was created by the gst-register command.
*
* The primary source, at all times, of plugin information is each plugin file
* itself. Thus, if an application wants information about a particular plugin,
* or wants to search for a feature that satisfies given criteria, the primary
* means of doing so is to load every plugin and look at the resulting
* information that is gathered in the default registry. Clearly, this is a time
* consuming process, so we cache information in the registry.xml file.
*
* On startup, plugins are searched for in the plugin search path. This path can
* be set directly using the GST_PLUGIN_PATH environment variable. The registry
* file is loaded from ~/.gstreamer-$GST_MAJORMINOR/registry-$ARCH.xml or the
* file listed in the GST_REGISTRY env var. The only reason to change the
* registry location is for testing.
*
* For each plugin that is found in the plugin search path, there could be 3
* possibilities for cached information:
*
* - the cache may not contain information about a given file.
* - the cache may have stale information.
* - the cache may have current information.
*
* In the first two cases, the plugin is loaded and the cache updated. In
* addition to these cases, the cache may have entries for plugins that are not
* relevant to the current process. These are marked as not available to the
* current process. If the cache is updated for whatever reason, it is marked
* dirty.
*
* A dirty cache is written out at the end of initialization. Each entry is
* checked to make sure the information is minimally valid. If not, the entry is
* simply dropped.
*
* Implementation notes:
*
* The "cache" and "default registry" are different concepts and can represent
* different sets of plugins. For various reasons, at init time, the cache is
* stored in the default registry, and plugins not relevant to the current
* process are marked with the GST_PLUGIN_FLAG_CACHED bit. These plugins are
* removed at the end of intitialization.
*
*/
/* Element signals and args */ /* Element signals and args */
enum enum
{ {