[gst-devel] Re: [gst-cvs] ds gstreamer: gstreamer/docs/random/ds/

[Benjamin Otte]

On Fri, 10 Dec 2004, Ronald S. Bultje wrote:

> > - each plugin has an associated registry XML file.  Each xml file in
> >   a plugin directory is loaded to create the in-core registry.
>
> GNOME and KDE *are* *definately* going to be annoyed by the increase in
> startup time. Weren't Linux and GNOME primarily slowed down by the fact
> that we open up gazillion of small files? This is another, ehm,
> une-hundred-something.
>
It doesn't say that we can't cache those registries contents in a binary
registry. Such an xml file is useful though if you want to gather
information about a plugin though without installing/loading the plugin.
As an example you could use it to generate xml files describing an RPM
with plugins. And you could then lookup these xml files and tell the user
he might want to install the missing plugin.

> > - needed for avidemux:
> >   <Company> plugin x create some registry information that says stuff like:
> >   <Company> "caps x are fourcc FOOO in avi"
> >   <Company> or "caps y may be contained in id3 tagged files"
> >   <Company> or "caps z is a valid format to put in an ogg container"
>
> And Benjamin just came up with avitypes, which was removed in
> 0.3.something or 0.5.something because it really just didn't work.
>
Looking at avitypes, I can see why it was removed. It's far too
complicated.
I'm just looking for ways that would allow adding new FOURCCs without
modifying rifflib. And I'm well aware that noone would use it if it were
overly complex :)
Other information I want to add to the registry is stuff like "you can
find a GtkWidget for displaying element X here" (useful in gst-editor,
Marlin or Pitivi) which shouldn't be part of the core either.

Benjamin