On Mon, Mar 19, 2001 at 08:05:04PM +0100, Wim Taymans wrote:
> "format", "float",
> "layout", "IEEE"
> "format", "int",
> "signed", true,
> "endian", "little"
> format is the subtype because it defines what other properties
> are allowed next. Think of it as an hierarchy or a union with
> a type to denote the contents...
I like, and I dislike. I like the plan of first having some type
information, and then a set of properties with the allowed properties
dependant on the type information.
I disklike because I don't see what advantage is gained by separating the
type into two pieces. I have a feeling that the main reason you want to
split the type into pieces is to preserve the integrity of the first part
of the type, which is currently a mime-type; ie, something whose allowable
values are defined outside of gstreamer.
I think the big bad thing about the system of having a format paramter
which controls which other formats are available is that it makes setting
up pad properties messy. Consider: I have a plugin which can accept
audio/raw in either float or int format. I have to write:
If the subtype were incorporated into the main type, I would have
(convention to name the main type to be decided):
This may not seem much different, but in my view its immensely nicer
because it gives you:
* One value, recognises specially by the system, which describes the set
of data, and which controls (together with a policy document) the
properties that that caps may have, and what their meanings are.
* Equality amongst the properties. There isn't one of them which is
especially important; since they all _look_ the same, they should _be_
* The ability to implement caps negotiation specially for particular
types. For example, to speed things up we might want to cache the
available properties of known types by making a hash out of their
values: to do this we need to know the type (int, pointer, bool) or
each parameter, and if there is only one value dictating the main
type, this becomes a lot easier.
I honestly can't see that we lose anything, either: I think the use of
mime-types is a nice idea, but not quite what we want, since too many
possible data types (spectral data, eg) don't fit neatly into a mime-type
Incidentally, are you writing endian as a string for any particular reason?
In the current docs, I've got it as an integer, possible values 0 or 1.
Would a string make more sense? Are there values other than big-endian and
little-endian that need to be handled?