[gst-devel] Meta-plugins: a proposal

[Thomas Nyberg]

On Sun, Mar 18, 2001 at 05:54:51PM +0000, Richard Boulton wrote:
> On Sun, Mar 18, 2001 at 05:03:26PM +0100, Thomas Nyberg wrote:
> > Then I propose the following:
> > The class of a plugin should consist of two parts(atleast) with them being
> > "firstpart/secondpart"
> > 
> > The firstpart should consist of the "media", and the second of the type.
> > Thus forming:
> > "Audio/Sink"
> > "Audio/Source"
> > "Audio/Filter" and so on...
> >
> > <etc>
> 
> Hmm - two main worries about this scheme:
> i) It doesn't seem to be a heirarchy: it's simply two properties of the
>    media.
> ii) It assumes that the type of the data processed is the most important
> property: I'd be inclined to say that what type of processing is done
> should be the top level property, what type of data it is done on is the
> next level, and what the name of the actual processing is should be the
> next level.  (eg "Decoder/MP3/mpg123")
> 

This is not the hiearchy of the filesystem/structure - but the naming of
a plugins _class_ - this I believe, should differ.

> Also, things to think about, to ensure sufficient generality, are:
>  What type would the example plugin (examples/plugin/example.[ch]) have?

>  What type would a tee have (since that can operate on any media type, it
>  shouldn't be Audio/, Video/ or AV/)

In my proposal these types would be called something like "Stream", it doesn't
work on the data itself, but rather on the streams. The media/types I
suggested are in no way complete - I only suggested what system I thought
would be the best.

> > <proposal to put definitions into a header file>
> >
> > This would make our lives easier if we choose to change the names, or add a
> > third part and so on... Also, it would make it easier to spot
> > spelling-errors for app-developers. _and_ it would serve as a central
> > repository for the availible types. No more confusion.
> 
> I think this is the wrong approach.  We should have a central place where
> we agree policy on types, but there is no need to attempt to enforce this
> policy by technical means.  Putting the types into header files reduces the
> flexibility of the system to accept new types: you need to update your
> whole system if you get a new type of plugin, for no good reason.
>
No, I think that you have missunderstood what I was saying. I only suggest
that we should use the headerfile to ease development. If you want to use
some other type, it is fine. By adding each type to the headerfile, developers
can safely use macros(#define's) to assign the types - this makes it less
probable that a spelling-error would occur. These types are added, when
they are needed. If you create a element that works on other types, it's
fine. 

The advantage of macros, is that it is easier to use them, than to write
the values yourself. If you create a plugin that works on the foobar-media,
instead of using GST_CLASS_AUDIO_SINK, you would simply use "Foobar/Sink".

In one way or the other, you will need a repository to store all types
"known to man" - a header-file works fine. This, as I've said before, 
limits the possibilities for spelling-errors.

If you've been programming with Gtk+ you know how irritating it is when
you misspell a signal. Think about how irritated you would be, misspelling
a class! By using defines this will be avoided(unless you count AUDIO
becoming VIDEO for a spelling error :).

/Thomas
-- 
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