I don't consider elements part of our interface.
App developers need to make sure they can cope with elements not being
available for any reason.

Elements, their properties and the implemented interfaces may change
between releases.

Other people will consider it part of an interface.  Just as any gtk
application developer would be annoyed if property names on gtk
widgets change between releases.

It's not because the element concept is more vague as an interface,
that it's not part of that interface :) I honestly don't see what
applications could currently do to figure out what name it should try
to factory_make on if we change names on plugins between releases.

The general idea is that you look for an element in the list that 
does your job and then select the one that best suits what you want 
to do.

Hardcoding element names totally stomps extensibility and to me is 
only a crude hack to get what you want.

If for example one day oilcolorspace is the best colorspace element, 
gst-player won't use that and insist on using ffmpeg. Same for 
volume (an element that implements the volume interface), 
colorbalance (... colorbalance interface), audioconvert (a converter 
that takes/outputs audio/x-raw-int) or filesrc/gnomevfssrc (... URI 
interface). The gconf keys already do this, too.

There is really no need to use element names. It's just simpler most 
of the time.

that's a pointless discussion :) there aren't good ways or good
examples of doing this, and with the current implementation there's no
way of fixing that.  There's no way in discerning between a filter
that takes float and gives back int but does some transform as well,
and int2floatnew.

Anyway, it would be very silly for us to suddenly say "don't use
element names" when we provide no alternatives that are sensible atm.

anyway, this needs to be resolved.

Everything I wrote is possible right now with elementfactories. 
(interfaces are stored in there).

The difference between int2floatnew and some other element is that 
int2floatnew is a converter while a plugin that would do different 
things is not.
It is certainly possible to specify every element that GstPlay uses 
(maybe apart from spider) by using element factories only.

It's just not done.

Naming things ...new is just dumb. What happens when it needs to
change again? ...reallynew? (or New College, founded in the 15th
century :-P) For testing, maybe ok, but for a release the old broken
element should just be _replaced_ with the new working one.

The only way to find an element in the gst-inspect list is for it to
have a sane name.

No, the best way to find it is to run gst-inspect without arguments 
and parsing the list it outputs. :p

Anyway, now that audioconvert has replaced both plugins, I think I 
can close this bug.