[gst-devel] 0.9 proposals

[David Schleef]

On Thu, Dec 02, 2004 at 03:55:40PM +0100, Martin Soto wrote:
> Not only for demux elements. Most complex elements would be a PITA to
> program using this model. I don't doubt Benjamin can make any element
> you throw at him work using this model, but I don't think most people
> will have the skills or, for the sake of it, the time and patience
> necessary to write elements this way.

Have you ever tried?  IMO, getting an element 100% right is easier
to do by 1) realizing you have a state machine, 2) designing a
state machine, and 3) implementing the state machine.  It's certainly
easier than 1) writing some code, 2) bug fixing hidden state
transitions in the code, and 3) realizing (oh shit!) that you have
a pooly-designed state machine.

Writing a state machine is not hard, it just requires planning and
a bit of noodle work.

> Additionally, the point of having
> a framework like GStreamer is to make things easier, not harder. Having
> to split elements this way in order to make them work seems to
> completely defeat Gstreamer's purpose.

This is a fallacy.  Back in the day, people wrote GUI apps in the
same way that they wrote CLI apps, and the GUI apps turned out
crappy.  Then some people started advocating smarter ways to write
GUI applications (object orientation, etc.).  The old-timers said
"But that's _harder_."  Nevertheless, all GUI apps today are written
using GUI app techniques.

I'm not saying that this situation is 100% the same, but I do know
that multimedia on Linux got a *lot* better when codec library writers
started writing in terms of being a good component in a larger system
rather than being the sole driving force in a CLI app.  We used to
bend over backwards to try to support such broken libraries -- now
we don't, because we can get away with not supporting poor programming
techniques.

GStreamer is, quite literally, breaking new ground in developing a
media framework that works "The Right Way".  I'm willing to entertain
the idea that doing so requires new programming techniques.



dave...