From: Christian F. K. S. <Ur...@li...> - 2002-10-27 11:47:25
|
Hi, Ok Thomas flamed me for wasting diskspace with my first proposal so here is an alternative one which keeps the system registry :) Christian GStreamer Registry Design GStreamer has a system registry in ${sysconfdir}/gstreamer stored as an XML file. For this registry we have no automatic registry rebuilding as it is updated when packages call gst-register (which they should) when installing or the sysadmin manually running gst-register. Running gst-register as root should make it search for plugins in: ${prefix}/lib/gst/lib /usr/lib/gst GStreamer also has one plugin registry per user. The registry is stored within $HOME/.gstreamer as a xml file. When an application calls the registry it first search the system registrt, if no suitable set of plugins are found there it calls the user registry. If no suiteable set of plugins are found in either registry 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 auto-rebuilding the user registry it should include the following directories: $HOME/.gstreamer/gst/lib/ ${prefix}/local/gst/lib /usr/local/gst/lib 'prefix' in the two examples abovem are 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. |