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

[Ronald S. Bultje]

Hey Jeffrey,

I just had a short talk with David and Benjamin on this thing, to make
sure we're still all on-track. We all really want this, let's start with
that.

So, part of the information may possibly be extractable from plugins.
Since not everyone has all plugins, we'll need caching of this
information, where it is stored separately online. Other information may
be added separately (without being extractable) and it has to be
possible to re-merge this. Perl has good options to allow this. The
point of being extractable is to have one single source of information.
this means that the plugin is always right. The information in the docs
is extracted for updating to synchronize.

The target audience is users, but really only users. Developers who need
advanced stuff have better measures of getting to this (gst-inspect, API
docs) than our website, I think.

On Fri, 2005-02-11 at 21:42, Jeffrey C. Ollie wrote:
> What kinds of information to gather:
> 
> 1) Element/plug-in name.
> 2) Short, one-line description.
> 3) Longer, more meaningful description.

Definately. 1) and 2) could be extracted from plugins (not necessarily
from sources, of course; running gst-inspect <elementname> to extract
the information is fine with me, too, really. Also a lot easier). 3 is
new and thus extra.

> 4) Pads:
> 	a) Listing of all pads.
> 	b) Capabilities.
> 	c) Description.

I don't think users need this. I would leave this out for now. Instead,
I would quickly describe (for appropriate elements) which mimetype the
element handles (sourcepad for encoders/muxers, sinkpad for
decoders/demuxers). Since this may be hard to extract (although not
impossible), you may want to not extract this for now. Up to you,
really.

> 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).

Good stuff. Not extractable, obviously.

> 6) Properties:
> 	a) Name.
> 	b) Description.
> 	c) Read/write or read only?
> 	d) Type (float, integer, string, etc.)
> 	e) Valid values.
> 7) Signals.

This is all developer stuff. If a user needs this, either his app sucks
or something is terribly wrong. I'd strongly recommend to leave this
out, it will swamp the user with info that isn't all that interesting to
him.

> 7) Platform availability (all platforms, Mac OS X only, anything but
> Windows, etc.)
> 8) CVS module/branch/revision number (or whatever) that indicates the
> version of the plug-in that is being referred to.

Right, probably useful. Something extra I'd like to see
(non-extractable), is a short status. Known issues (possibly with links
to bug numbers in bugzilla), special supported/unsupported features
(e.g. 'seeking doesn't work' for ADTS/AAC MPEG-4 (.aac) or raw MPEG-2
video (.m2v) files). Those sort of things. Basically another small
description, possibly a dotlist for issues or so.

> 1) Learning about the plug-ins that are available so that gstreamer apps
> can be developed.

Right, so that's probably not a good focus. It's good to see what we
support. However, as soon as you need technical stuff, there's better
and more uptodate needs, such as gst-inspect or the API docs. It *may*
be possible to see what we support, which is also a good thing for app
developers, but I wouldn't focus too much on this.

> 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.

Exactly!

> 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. Benjamin actually brought this up, to. He'd like to have an
auto-download feature for missing plugins in Totem (or RB). Really cool
stuff of course, something that we may be able to do based on your
efforts as a next step (that's where XML gets really useful besides
parsing into nice HTML).

Last thing, Dave had some concerns on the amount of source files. This
is not all that information, so you could put it all in one huge source
(XML) file, but you could also do one source file per plugin or so. Dave
has a light preference for the first, I for the second, but we don't
care all that much. Choose whichever you're more comfortable with. Put
it in a separate directory for now, so the source tree doesn't get too
cluttered (which would be bad).

Hope this is useful, and sorry for taking a few days (I was gone... ;-)
),

Ronald

-- 
Ronald S. Bultje <rbultje at ronald.bitfreak.net>