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

[Jeff Mitchell]

Hey folks--

I'm new to the project, and I'm going to be taking a crack at the
status table issue.  Upon looking at the way things are set up right
now, I have a proposal for a new file that I believe would solve some
problems.

Currently there is a GstElementDetails struct in each plugin that
contains a very small amount of information about the plugin.  The
mime types are located elsewhere.  This means we already have bits of
info (and maybe more I'm not currently aware of) located in two
different places in the code, neither of which are complete.  What's
more, some developers feel that the extra information that should be
added (long description, status, etc) do not belong in the source
code, so adding even more information about the plugin to somewhere in
the source code will not only make little sense, but cause whatever
conversion tool I write to have to parse more than is necessary,
leading to a longer running time and greater possibility of errors. 
Also, the more locations you have for information, the harder it is to
remember to update all of them.

I think it'd be a much better idea to have all information in one
place.  Maybe some replication in the code of what's currently in
GstElementDetails (I know some of you hate replications) but maybe
even phase that out.  Even if the information was kept in the source
code, all of the information would have to be in some standard format,
delineated in some standard way, so that the tool I write can find it,
so why not put it in a standard language?

I propose a new file, written in XML, that is included with each
plugin.  It could have default values that a plugin author could
change, making it very easy in most cases to provide all necessary
information.  Because of the nature of XML and the fact we can write
our own schema or DTD, this file could easily be extended to handle
new data as it is seen fit and still have all data be validated.

A quick example of what I'm thinking of (there may be some well-formed
errors in the example, just accept it as is for now) is below:

<plugin>
     <name>My plugin</name>
     <author>Jeff Mitchell</name>
     <shortdesc>A plugin that decodes some type of audio.</shortdesc>
     <longdesc>My plugin does a whole ton of decoding, actually. 
Check it out and see for yourself.</longdesc>
     <mimetype>catergory/type1</mimetype>
     <mimetype>catergory/type2</mimetype>
     <status type="beta">
          <major>0</major>
          <minor>12</minor>
     </status>
</plugin>

Using a standardized name for these descriptions, I could make a
Python script to traverse the plugins tree, parse out the data, and
get it ready for the website; this could be run at each build of
gst-plugins.  An alternate proposal was that these files could reside
in the www module in CVS, but I think that a lot of plugin authors
might forget to update that when they release a new version of their
plugin, as many may not even have the www module downloaded.

Anyways, I'd like to hear suggestions and comments.  Some of the
things I'd especially like to hear are:

1.  Regardless of how the data is stored, what data fields you feel
should be contained in the status tables.  The example above is by no
means an exhaustive list of what could be contained in them, just a
quick and dirty example.

2.  Any serious objections or serious approvals of this proposal.  If
I get no serious objections, I'm going to assume it's okay with
everyone.

3.  Anything else you can think of that is relevant.

Thanks,
Jeff