[gst-devel] Design proposal for the GStreamer registry

[Christian Fredrik Kalager Schaller]

We have some useability issues with the way the current registry setup
works. Specifically it often calls on the users to run gst-register as
root which we do not really want. I have been mulling over the design
for the registry for some time now trying to come up with a plan on how
to handle system/user registry interaction. Well last night I asked
myself the fundamental question: why do we need a system registry. After
that a design seemed simple. So here is my proposal for how the registry
should work. Let the flames begin :)

GStreamer Registry Design

GStreamer has one plugin registry per user. The registry is stored
within $HOME/.gstreamer as a xml file. 

When an application calls the registry, if no suitable set of plugins
are found there it should try rebuilding the registry. If still no
useable plugin is found this should be reported back. This might be a
slow process if the user tries again and again, but we must be allowed
to assume that if the user is told that format xy needs a new plugin
installed to be possible to play that they stop trying.

When rebuilding the registry it should include the following
directories:
$HOME/.gstreamer/gst/lib/
${prefix}/lib/gst/lib
${prefix}/local/gst/lib 
/usr/lib/gst/lib
/usr/local/gst/lib

prefix is here the the prefix that GStreamer was installed into.

The user registry should at all times contain a full list of plugins. 

Other registries:
We might want to add other types of registries in the future, like the
discussed web registry. We should probably have a concept of priorities
in the registry search concept.
The user registry should always be priortity 1, rebuilding the registry
priortity 2, and for instance a web registry could be priority 3. If we
at some point add even more registries we can either just give them
priorities behind the others or re-order the priorities if that is the
obvious choice.