[gst-devel] Meta-plugins: a proposal

[Richard Boulton]

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

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

We should have convention dictating what case should be used for type
names.  I think dictating that the start of a word or acronym should be 
upper case, and the rest of the word or acronym should be lowercase, would
be the neatest scheme.  So we get "Decoder", "Mp3", "Mpg123", "Xmms",
"Ladspa", etc.  Alternatively, we could dictate always lower-case.  I think
we should specify _some_ particular scheme, though.


Hmm - I seem to be saying I don't like your suggestion at all.  But that's
a positive thing, because its making me see what's good about wtay's
original suggestion...  Please take no offense: none is intended.


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


Thanks very much for the feedback.

-- 
Richard