-- property proxy in compount elements.
-- implement events in all plugins.
-- app must be able to catch events?
-- deal with clocking issues
-- use real chaining where possible
-- factory aliases?
-
-* gst_elementfactory_make ("factoryname", NULL) automatically uniquifies the name
-* a plugin test rig
-* parser and scheduler test system
-* clean up xml code - restore/save creates/save pipeline, gst_object_save/load_props
- with just the properties
+TODO:
+-----
+
+short term core API stability
+-----------------------------
+
+Changes that probably impact the API, carefull discussion (IRC) + design doc is required
+before changes are accepted.
+
+target release ! description
+ !
+ 0.4.1 ! expose and API to query the supported seek formats/flags on
+ (done) ! pads, somthing like an extra arg to gst_pad_set_convert_function
+ ! and gst_pad_set_event_function with some function to query the
+ ! flags and formats. more ideas in docs/random/wtay/query_events
+ ! (API: medium dificulty)
+ !
+ 0.4.1 ! add event for segment playback/looping and seeking (docs/random/wtay/segments)
+ (done) ! (API: medium dificulty, plugins: HARD to very HARD)
+ !
+ ? ! add event to adjust rate (reverse playback, slow motion, frame skipping)
+ ! (docs/random/wtay/rate_event)
+ ! (API: medium dificulty, plugins: HARD to very HARD)
+ !
+ ? ! add method in the scheduler to set the entry point (frame stepping?)
+ ! (docs/random/wtay/scheduler_entry)
+ ! (API: moderatly EASY, scheduler implementation MEDIUM)
+ !
+ 0.6.0 ! create a design doc for a timecache implementation,
+ (done) ! (docs/wtay/random/timecache)
+ ! (API: MEDIUM, needs lots of discussion, plugin implementation MEDIUM to HARD)
+ ! (done: implemented using GstIndex base class + subclasses)
+ !
+ ? ! implement a QoS event and a policy for handling the event.
+ ! (API: kindof EASY, plugins MEDIUM to very HARD)
+ !
+ 0.4.1 ! implement user defined GstFormat values, make a format factory etc..
+ (done) ! (API: MEDIUM, plugins MEDIUM)
+ !
+ ? ! strip the API to a bare bones minimal set of functions, leave the automatic
+ ! stuff to the app instead of forcing a policy in the core.
+ ! create a library with usefull higher level function for people who don't want
+ ! to deal with the lowlevel stuff.
+ ! (HARD, need to negotiate with people :))
+ !
+ ? ! use GMarkup to load/save objects, remove dependency on libxml2
+ ! (MEDIUM) breaks API/ABI compatibility
+ !
+
+
+shortterm core feature enhancements
+-----------------------------------
+
+ 0.4.1 ! Implement PAD_DISABLED. This requires simple checks in the scheduler so that
+ ! it doesn't try to pull/push data from/to a disabled pad.
+ ! When an element goes to the PAUSED state, all of its pads should be disabled.
+ ! This should also work for ghostpads.
+ ! (API: MEDIUM to moderatly HARD, requires some scheduler understanding)
+
+
+short term usability
+--------------------
+
+Writing docs is NOT boring, you learn a lot, you get insight in stuff, you help a lot
+of people, hey! you might even find YOUR book on a shelf in a bookstore!!
+
+
+ ? ! plugin writers guide
+ ! (we have almost nothing, so any start is welcomed)
+ ! (MEDIUM)
+ !
+ ? ! app writers guide needs to cover common tips and tricks and HOWTOs
+ ! (MEDIUM)
+
+
+short to midterm policy definition
+----------------------------------
+
+Policy definition is closely related to a HOWTO but sometimes needs some thinking.
+
+
+ ? ! document thread safety guidelines, what stuff needs locking in the app, what
+ ! is done in the core.
+ ! most of this stuff is in the heads of various people but needs to be written
+ ! down so that people get more insights into the design and vision of GStreamer.
+ ! (MEDIUM, some research and discussion needed)
+ !
+ ? ! a step by step guide to the implementation of various events in a plugin, what can you
+ ! do, when is data passing forbidden etc..
+ ! (MEDIUM, some research needed)
+ !
+ ? ! figure out a policy for the NEW_MEDIA event
+ ! (MEDIUM to HARD)
+ !
+ ? ! figure out how to better handle clock resync
+ ! (MEDIUM to HARD)
+ !
+
+
+midterm feature enhancement
+---------------------------
+
+ 0.6.0 | Define and implement a syntax in gst_parse to handle filtered pad connections.
+ (done) | (MEDIUM)
+ |
+ ? | Figure out a way to set properties on schedulers (and bins?) from gst_parse.
+ | (MEDIUM)
+ |
+ ? | Make gst-inspect do inspection of plugins, schedulers, autopluggers, types.
+ | An idea would be to make -inspect output an XML representation of the objects
+ | and use XSLT to transform this into text, HTML, docbook, ...
+ | (MEDIUM to EASY)
+ |
+
+
+midterm (longterm) optimisations
+--------------------------------
+
+These optimisations can be done without changing the existing API.
+
+
+ (in progress) ! implement an optimal scheduler that uses chaining when possible
+ ! (HARD, requires detailed knowledge of element scheduling)
+ !
+ ? ! alternatively optimisations to the current scheduler can be done such
+ ! as: do nothing when the pipeline structure (or chain) has not changed
+ ! (MEDIUM)
+ !
+ ? ! GstQueue is a little mess. implement a better queue (lockfree?), refactor
+ ! queueing policy (max buffer, max time, levels etc..)
+ ! (MEDIUM to farily EASY)
+
+
+longterm feature enhancements
+-----------------------------
+
+Various features that are not critical yet.
+
+ ? ! factory aliases. map a generic name like "videosink" to and actual
+ ! user configurable plugin (aasink, sdlsink, xvideosink, ...)
+ ! (MEDIUM)
+ !
+ ? ! property proxy in compount elements. not sure if it's possible at all.
+ ! what with elements with the same property?
+ ! (MEDIUM, needs some thinking)
+ !
+ ? ! Make _pad_select work for muxers
+ ! (MEDIUM to HARD)
+
+
+needs consensus
+---------------
+
+Some stuff that needs to be figured out based on a pro/con comparison.
+
+ ? ! can we decide on the fact that downstream events are traveling using the
+ ! scheduler? do we need to reevaluate that design decision?
+ ! (MEDIUM, needs pros vs cons document)
+
+
+benchmarks
+----------
+
+Benchmarks are always good to get acceptance in a wider comunity or to identify performance
+problems that need fixing.
+
+ ? ! do a latency comparison with popular other frameworks, document GStreamer
+ ! overhead.
+ ! (MEDIUM to somewhat EASY)
+ !