[gst-devel] plugin directory/hierarchy

[Thomas Nyberg]

On Wed, Mar 07, 2001 at 11:53:19PM +0100, Wim Taymans wrote:
> On 07 Mar 2001 23:39:07 +0100, Thomas Nyberg wrote:
> > On Wed, Mar 07, 2001 at 10:14:16PM +0100, Wim Taymans wrote:
> > > In GStreamer all plugins are techically filters, the only way they
> > > can be considered sources or sinks (input/output) elements is
> > > by the absence of src/sink pads. 
> > 
> > This really sucks!
> > If you are writing an application, you should not assume that a given
> > plugin exists on the system. Perhaps you want to use an alas_sink if it
> > exists - else an oss_sink. Perhaps someonee has renamed the oss_sink into
> > audio_output-sink. This is a real problem I believe.
> 
> not really.
> An app programmer will use the hierarchy as a global plugin selection
> mechanism. When
> you want to select a plugin, you're always going to query the repository
> for a plugin that
> can, say, convert raw audio to mp3 using the capabilities of the pads.
> The new autoplugger
> lets you do super-repository-queries. As an app programmer you don't
> even want to know 
> what plugins are needed to do a certain conversion at all.
>

Imagine the case where the app-programmer wants to find out which filters
are present on the system. To make it more interresting look at the case
where the programmer wants to add support for LADSPA-filters. In this
case there is no way of knowing which filters are availible. The names
are created at run-time, which makes prediction somewhat hard.

Here it would be really easy to just be able to query which factories
creates a filter. Another case is when you have multiple soundcards on
the system - in one way or the other you must be able to determine
what is availible and what is not.

One way of solving this might be to create helper-functions that
"simulates" this behaviour. It does the analasys for you and it
becomes more or less trivial for the app-programmer to determine if
this is a output-filter or just an ordinary filter.

> > Instead of using Sink/Audio, one could use a enum(whatever...) like
> > enum {
> >      SINK = (1 << 0),
> >      SRC = (1 << 1),
> >      AUDIO = (1 << 2),
> >      VIDEO = (1 << 3),
> >      PARSER = (1 << 4),
> >      ...
> > };
> > 
> 
> The problem with all those flags is that they tend to tie a lot of
> semantics to the core (in
> header files somewhere). If you want to add something completely new
> (like 3D objects)
> you'll end up having to add another flag in the enum..
>
Yes, this is unfortunate. However, it might be possible to allow for
an SPECIAL-enum to exist - but your argument is still valid.

> > Since an application can test each element-factory present on the system one
> > can cope with name-changes, "3rd-party"-plugins and so on... 
> 
> So can it when we clearly define the hierarchy...
>

This I do not agree with - somehow you need to create a hierarchy that is
traversable at runtime by the application. Imagine the case wher you have
multiple soundcards. Your application wants to allow the user to select
from this list of availible soundcards. There is no way to guess in advance
what cards are availible on any given system. Therefor the application will
have to traverse _something_ to get this list.
In this case you can't have an autoplug-thingy that does the job _for_ you,
since it is the user that determines this at runtime.


Taking LADSPA-filters as example, again, you might have hundreds of these.
It becomes pretty hard to not have some type on these that it is easy
to browse and traverse by the application. Name alone, is not sufficient.
There has to be a type associated. Since adding a completely new type
of filter requires a total recompile in the case when an enum is used,
enums should probably _not_ be used.

However, something similar could and should still be used.
If you were to create some nice #define's (discard naming here)
#define TYPE_AUDIO "Audio"
#define TYPE_SINK "Sink"
#define TYPE_FILTER "Filter"

You get the advantage of easy spell-error-recognition, you move the actual
values away from the "user"(which is good), and you can easily add types
at will. In this case, you wouldn't have to change anything to still being
able to use a 3d-object or something.


You could construct the hiearchy by a naming convention(similar to mime),
like media/type. An example of a audio-output-thingy would become
"Audio/Sink", and encoded in a nice way you could make it look like:

...
GST_xxx_LIST (
  GST_xxx_TYPE(TYPE_AUDIO),
  GST_xxx_TYPE(TYPE_SINK)
)
...

This way, one can test these values easily - and the app-programmer can
be fairly certain that he compares the different values correctly. Since
the chance of spelling-errors are low - and the names are set as #define's
in a header-file somewhere.

If a "3rd-party" creates a 3d-object-element, nothing stops him/her from
using
GST_xxx_TYPE("3d-thingy") instead of perhaps GST_xxx_TYPE(TYPE_SINK)


/Thomas <thomas at codefactory.se>

-- 
Thomas Nyberg                    thomas.nyberg at codefactory.se
CodeFactory AB                   http://www.codefactory.se/
Office: +46 (0)90 71 86 10       Cell: +46 (0)70 335 61 64