[gst-devel] Proposal for XML Description File for Plugins

Jeff Mitchell jeff.mailinglists at gmail.com
Wed Feb 9 18:23:08 CET 2005

> 1) create the status table without needing manual updates. (This is how
> gst-inspect works.)
> 2) find missing updates automatically and make them break the build. (This
> is how our documentation building works.)
> Binary extraction would be step 1). A manually updated XML file (or
> multiple manually updated XML files) would be the exact same problem as
> before.

I guess a big part of the issue here is what exactly we want in the
status tables.

The information has to be provided somewhere, which means that manual
updating has to occur at some point.  gst-inspect provides the details
in GstElementDetails, for instance, but if we want to add field foobar
in there with another piece of relevant information, that info still
has to be added somewhere into the code for gst-inspect to gather it. 
At which point other code may need to be changed because the structure
of the GstElementDetails struct as changed.

There's some information that can only be provided at runtime, but how
much of that do we need/want in the status tables?  Looking at the
output of gst-inspect, I don't know the answer to that question
because for the most part I don't know what of that information was
generated dyanmically, but I'm guessing most of it will not be
relevant.  That's kind of why a set of data needs to be agreed upon.

Also, there are other things that I'm not sure gst-inspect provides. 
For instance, dependency information.  The only thing that looks
somewhat like it provides dependency information would be something
like this (using the output of gst-inspect alsasink):


Sure, this provides information saying that GstAlsaSink depends on
GstAlsa.  What about the fact that GstAlsaSink depends on ALSA itself?
 It may seem obvious to all of us, but the fact is that it's a
dependency that is not listed as such in the gst-inspect output.  What
if we want to add a hypertext link to the ALSA project, or to any
useful pages on getting ALSA to work with Gstreamer?  This kind of
information needs to be manually entered anyways, regardless of
whether it's in source code or a XML file, but adding it as a new
field in the source may require changes elsewhere and may require
changes within gst-inspect itself, every time we add a new piece of
info.  (What about multiple pieces of the same type of info, like
multiple reference links?)

I'm sure someone (or many people) are thinking, the old status tables
didn't have reference links, and these don't need them either.  True. 
It's just an example of something that may be useful to people looking
at the status tables.  The ones that existed before didn't have all
that much information really...

So if it wasn't obvious, I think we need to figure out exactly what
information we want in the status tables.  Then we can figure out the
best way to get that information.  I think one of three things will
end up happening:

1)  We use the output of gst-inspect.  Adding new information to the
output is a pain: plugin source code must be changed, gst-inspect
might have to be changed.  Developers have to keep any information not
dynamically generated up-to-date in the source code.  Updating the
status tables will have to either rely on all plugins being up-to-date
and built on the local machine or perform a lengthy build of the
entire plugin tree.  Plugins that cannot be built by the script (like
maybe sunaudiosink) have to get the information from somewhere else.
2)  We use the output of gst-inspect plus a second source.  This
allows for easier extensibility (any new information desired could be
put into the second source) and allows more information to be gleaned
automagically, but it suffers from the problem of developers needing
to keep the information up-to-date in both places, and it makes the
script more complicated.  Local copy/lengthy build problem still
3)  We use only a separate source.  Allows for the most extensibilty;
source code of plugins and gst-inspect do not need to be changed to
add extra status information.  No lengthy build needs to be made by
the script or rely on a local copy of the same version.  Developers
have to keep all relevant information up-to-date, but this may not be
much more than using 1) or 2) depending on how much information we
want in the status tables that can and can not be gotten from

Unless we only want the information that's currently in the output of
gst-inspect, the information is going to have to be manually added,
whether to the source code or a XML file.  So a "manually updated XML
file would be the exact same problem as before" is probably true, but
depending on the fields we want in the tables, manually updated source
code will the the same problem as well (already you need to manually
update the source code if, say, the autor's email address changes --
updating any other kind of file with this information wouldn't be any
harder).  Either way, developers would need to just take the minute or
two required to update the information from its previous incarnation.


More information about the gstreamer-devel mailing list