No subject

cases, and some code.  The goal is to get all the cases written into code,
in the form of a regression test.  Once that is reasonably complete and
fully passing, we can finally consider the meat of INCSCHED finished.

Other issues center around thread-safety.  We need to determine what
pieces of code can be run simultaneously with other pieces of code.  Of
course, for thorough testing of this we need constant access to a
dual-processor or better machine.  We'll have to figure that out at
RidgeRun somehow, and/or enlist taaz, who's always been a supporter of
test suites <hint>.

Some examples:

1) setting an argument from the application could potentially cause
problems when the code runs simultaneously with the element's code that
uses it.  We can solve this with some carefully placed locks.  I recently
added a lock that's acquired any time a given cothread is running.  We can
construct a GstElement-level set_arg/get_arg pair that acquires this lock
on the current cothread (via the scheduler), and calls a GstElement class
method by the same name (set_arg/get_arg) that actually does the work.
This allows us to guarantee that the set_arg/get_arg happens when the
element is not running.  Making it lightweight is a bit of a challenge,
but can be done.

This method has the advantage that we can override the GstElement's
set_arg/get_arg functions to handle out-of-proc elements as well.  We
simply supply our own functions to each element's class as they are added
to an out-of-proc container.

2) modifying a pipeline from another thread is very dangerous.  We need to
make sure that any changes to the pipeline are done with the pipeline in a
state that is safe for these operations.  This will by definition have to
be implemented partially as code and partially as policy.

4) with the switch of PLAYING and PAUSED, we need to rework the thread
interlock code.  This should be fairly straightforward.

After this is settled, the release has been made, and there's been some
general cleanup, it comes time to do two things: switch to glib 2.0 and
gobject, and restructure CVS.  These can happen somewhat in parallel,
since the glib switch only touches gst/, and the restructuring only
touches plugins/ and libs/.

Other things to plan for:

event system
reworked player core
new edittor
remoted containers
...more plugins!

And that ignores the issues that the GNOME Sound Server and
linux-audio-dev stuff will bring to the table.  The GNOME stuff at least
has a deadline....


So, the plan is: matth, brentb and I will try to verify and complete
INCSCHED, then merge it into HEAD.  At the same time, everyone else should
be making a list and checking it twice, containing all the things that
need to be known to work for the 0.2.0 release.  The very first item is
gstplay, which should be everyone else's top priority to get functioning
one way or another.  That could mean a) patching it to not kill incsched,
b) taaz's suggestion of hard-wired pipelines for common file types, or c)
get the new autoplugger fully online for renderer pipelines.  I'd attack
them in that order, until something works.

/me sleeps now

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