[gst-devel] Complexity estimation

[Erik Walthinsen]

I realized that we keep getting into the situation where we can keep
coming up with more and more complex scenarios for a given problem.  This
is most evident when trying to work out EOS and partial state.  I would
propose that we come up with metrics for estimating complexity of an
application, and use those to decide whether we should solve the problem
or let the application deal with some of the complexity.

I'd suggest the following categories of applications and features:

Trivial
Simple/Standard
Hard
Insane

Trivial and Simple are the most common, and I assert that these two levels
should allow the application to be coded without any special knowledge
beyond what's in the App Manual.  Go any higher, and you risk needing to
read through the Design Manual (which I've started to write), and even the
code.  Mucking with internal structures would not be beyond an Insane
applications's scope.

Examples:

Trivial:
	fakesrc ! fakesink
	disksrc ! mpg123 ! audiosink

Simple:
	Basic DVD player
	Disk-recording Icecast player

Hard:
	Complete DVD player with switchable languages/subtitles
	Audio mixing system

Insane:
	NLE
	Audio workstation

Then we need to categorize and sub-categories various features, assigning
some level of complexity to them, i.e.:

Autoplugging of Always pads: Trivial
Autoplugging of Sometimes pads: Simple
Autoplugging with multi-path: Hard
Autoplugging in dynamic pipelines: Potentially Insane
Normal EOS: Simple
Branched and partial EOS: Hard
Dynamic pipelines: Hard
Partial state: Hard
Mutliple partial states: Insane

Now, these levels allow us to punt to some extent.  In the case of
mutliple partial states (e.g. one part of pipeline goes EOS at the same
time another goes PAUSED), the application had better know a heckuva lot
about the pipeline, and have its fingers all over the place to monitor
state and make sure nothing goes wrong.  This means we need to provide API
as necessary to allow it to do this monitoring and control.

This doesn't mean that we can ignore the Hard or Insane cases, just that
we have to realize that there are times when the application just has to
be smarter than the core library, else the core library becomes both
unmanageable and slow.

"Make the easy things easy, and the hard things possible."

We just have to decide when to stop obsessing over ever possible scenario.  
And I'm the primary offender here, so remember to slap me around as
necessary.


      Erik Walthinsen <omega at temple-baptist.com> - System Administrator
        __
       /  \                GStreamer - The only way to stream!
      |    | M E G A        ***** http://gstreamer.net/ *****
      _\  /_