[gst-devel] What I want out of a "Status Table"

[Jeff Mitchell]

> 
> What this information would be used for:
> 
> 1) Learning about the plug-ins that are available so that gstreamer apps
> can be developed.
> 
> 2) Learning about plug-ins that are not available on the current system
> so that appropriate dependencies can be installed and plug-in can be
> made available.

These sound like good answers to the questions Darren posed in the
other (dead) thread.
 
> Ideally, this information would be available both to gstreamer-based
> apps (gst-inspect, totem, etc.) and on a web page. Also, the
> information should _not_ be limited to the plug-ins that have been
> compiled on (or installed on) a particular system because part of the
> point (and where the current gst-inspect fails) is learning about plug-
> ins that are available in the gstreamer source but have not been
> compiled/installed.

Good points and I agree with both, ideally, although we'll have to see
if this is possible once our final data model is defined.  For
instance, making some of this information available to gst-inspect may
require reworking gst-inspect code and APIs, while making other
information available in the web page may require data to be pulled
from gst-inspect, which violates the second ideal above.  For now,
however, this is an implementation question and we'll deal with it
later...first we'll figure out what we want, then figure out how to do
it (or why we can't).

I also wanted to comment on something Darren put on the previous (dead) thread.

**snip**

It seems to me
that if one of the goals of this is for this to be a stop gap solution
of sorts for totem users and the like to go find missing plugins and the
like, it would be MUCH better to have totem just say directly to the
user you are missing plugin x, go to y to download and install what you
need... I had a random thought that perhaps this status table could be a
way to collect, update and get a working maintenance process around some
of data you might need to improve gstreamers error handling for these
error cases...

**snip**

This would be really neat if Totem could do this -- although such a
capability would hopefully be handled by a library so that other
Gstreamer-compatible players could also perform this function.

I believe if such a system is introduced the data for what plugin is
missing and where to download it from will need to come from the
Internet.  I'm not sure that the status tables would be a good way to
figure it out, however...this would require some parsing of HTML which
presumably would be formatted in a specific way, but that way could
change if, say the tool converting the XML to HTML changes for some
reason.  So another way may need to be found.

I wanted to bring this to light to get it on people's minds, because
if we want to try to get this information from the status tables all
the information necessary should be defined in the data model.  All
necessary information may already be based on the data Jeff requested:

5) External library dependencies:
       a) Name of library.
       b) Link to "home page", not just where the source tarball can
          be downloaded.
       c) Version numbers that are compatible (where known).

But I'm not sure if any other information would be useful (maybe the
possibility of multiple links?), so if you'd like to see such a system
get set up eventually and want to have the option of basing it on the
status tables, make sure that you request any information that you
think would be useful.  Let's wait on discussing implementation
details for this system, though (unless you think it should be
unrelated to the status tables, in which case maybe open up another
thread).

Also, if anyone wants me to explain my rationale for why I think the
data for such a system should be downloaded fresh from the Internet
each time it's looked up instead of relying on information on the host
system, I will be happy to -- shoot me an email or open up a new
thread.

--Jeff (the New One)