Added status of the documents

Original commit message from CVS:
Added status of the documents

docs/random/arch

@@ -1,3 +1,6 @@
+OUTDATED
+--------
+
 GstElementFactory:
 
 Base class for all elementfactories.  Is a single-instance (per program)

docs/random/autoplug1

@@ -1,3 +1,7 @@
+COMPLETELY OUTDATED
+-------------------
+
+
 A little explanation of the first autoplugger in GStreamer:
 
 Autoplugging is implemented in the following places:

docs/random/buffers

@@ -1,3 +1,7 @@
+METADATA ON BUFFERS IS OUTDATED
+-------------------------------
+
+
 Buffer mutability properties are the most important part of gst, and
 similarly are the most complex.
 

docs/random/caps

@@ -1,3 +1,7 @@
+SOME OF THE FIRST IDEAS, PRETTY OUTDATED
+----------------------------------------
+
+
 During the course of a discussion on IRC, it turned out
 that there are many possible ways to handle the capabilities.
 

docs/random/company/gstdata

@@ -1,3 +1,6 @@
+STATUS: GstData is not implemented as a class for speed reasons.
+----------------------------------------------------------------
+
 NB: This document does not represent the current state of CVS but my current plans on how to implement this.
 
 Basics

docs/random/dynpads

@@ -10,14 +10,14 @@ and properties of a pad can be obtained from the elementfactory using
 the padtemplates. 
 
 Dynamic pad usually have the presence indicator set to 
-GST_PAD_FACTORY_SOMETIMES. This indicated that the pad might become
+GST_PAD_SOMETIMES. This indicated that the pad might become
 available at runtime. When the pad is actually created in the 
 element, the element will signal the new_pad signal. This signal can
 then be used to attach a desired (compatible) element to the 
 pad.
 
 For certain elements, like a tee and a muxer, we need another pad 
-presence flag: GST_PAD_FACTORY_REQUEST. With this flag, the 
+presence flag: GST_PAD_REQUEST. With this flag, the 
 elementfactory will announce that some of the pads are available on
 request. For the tee element, for example, one might obtain a new output
 pad by looking up a suitable padtemplate (temp) and performing:

docs/random/eos

@@ -1,3 +1,6 @@
+OUTDATED
+--------
+
 
 case 1) 
 

docs/random/events

@@ -1,3 +1,6 @@
+EARLY DOCUMENT, NOT EXACTLY AS IMPLEMENTED
+------------------------------------------
+
 EVENTS RFC
 ==========
 

docs/random/example

@@ -1,3 +1,7 @@
+OUTDATED, methods have different names now
+------------------------------------------
+
+
 Here's a pipeline that does audio/video MPEG streams with a queue on
 either side of each decompressor, for a total of 5 threads (read/split,
 decode audio, decode video, play audio, play video):

docs/random/hierarchy

@@ -1,3 +1,7 @@
+OUTDATED
+--------
+
+
 Face it, the plugins/ directory hierarchy is crap. We want to propose a
 better layout for it now. Some things to consider:
 

docs/random/intro

@@ -1,6 +1,5 @@
 GNOME Streamer is a pipeline-based media streaming framework.  It is built
-on top of the Gtk+ object model, and while it currently sits on top of
-gtk, it can be divorced from it at any point in the future.
+on top of the gobject object model.
 
 A pipeline consists of at one or more each of sources, sinks, and filters.
 These elements may be combined inside container elements, which may have

docs/random/metadata

@@ -1,3 +1,6 @@
+OUTDATED
+--------
+
 The point of the metadata is to provide some context for each buffer.  In
 the case of audio data, for instance, it would provide the samplerate, bit
 depth, and channel count.

docs/random/omega/eos.old

@@ -1,3 +1,7 @@
+OUTDATED
+--------
+
+
 What I propose for EOS condition is th following:  As is stands, EOS is a
 flag in a buffer.  However, it's also a signal from an element, which is
 odd. What I propose is that EOS become a pad thing.  Here's how it would

docs/random/omega/pad-negotiation

@@ -1,3 +1,6 @@
+OUTDATED, EARLY IDEA
+--------------------
+
 When two pads are connected, a negotiation phase is going to have to
 happen.  Ideally, the caps of the two pads will both be fully-specified,
 and match.  That's the ideal case, but may rarely happen in practice.

docs/random/omega/padtemplates

@@ -1,3 +1,6 @@
+OUTDATED
+--------
+
 typedef gpointer GstCapsFactoryEntry;
 typedef GstCapsFactoryEntry GstCapsFactory[];
 typedef GstCapsFactory *GstCapsListFactory[];

docs/random/omega/plan-generation

@@ -1,3 +1,6 @@
+OUTDATED
+--------
+
 Plan generation happens at transition from NULL to READY (and PLAYING to READY right now, need to fix
 that).  By way of some logic in gst_bin_change_state(), gst_bin_create_plan() is only called for the
 outer Bin, usually a Pipeline.  This keeps things from getting nasty later on.

docs/random/omega/sched-commit1

@@ -1,3 +1,6 @@
+STATUS: pushregion/pullregion is gone
+-------------------------------------
+
 Changed the way things are scheduled, especially sources.  A Src used to
 have a push() function, and optionally a pushregion() to deal with async
 reads, etc.  That whole thing has gone away, in favor of providing a

docs/random/omega/scheduling

@@ -1,3 +1,6 @@
+STATUS: pull on srcpads is outdated, they use _get
+--------------------------------------------------
+
 0) definitions:
 
 All pads without further specifiers are assumed to belong to the element

docs/random/omega/type-properties

@@ -1,3 +1,7 @@
+OUTDATED
+--------
+
+
 A type properties system might look like following:
 
 

docs/random/plugins

@@ -1,3 +1,7 @@
+SOMEWHAT OUTDATED
+-----------------
+
+
 We describe how the plugin system works.
 
 Plugins

docs/random/states

@@ -1,3 +1,7 @@
+OUTDATED
+--------
+
+
 GST State Bits and Transition Rules (graph to follow)
 -----------------------------------
 

docs/random/states.new

@@ -1,3 +1,6 @@
+OUTDATED
+--------
+
 Since the plan generation only happens as a result of the state mechanism,
 I'll describe that first.
 

docs/random/states.old

@@ -1,3 +1,6 @@
+OUTDATED
+--------
+
 GST States and Transition Rules (graph to follow)
 -------------------------------
 

docs/random/types2

@@ -1,3 +1,7 @@
+OUTDATED
+--------
+
+
 1. Introduction
 ---------------
 

docs/random/types3

@@ -1,3 +1,7 @@
+SOMEWHAT OUTDATED, design still holds though
+--------------------------------------------
+
+
 1. Introduction
 ---------------
 

docs/random/walkthrough

@@ -1,3 +1,6 @@
+OUTDATED
+--------
+
 You might start by creating a source element and put it into a pipeline.
 At this point both element's state would be GST_STATE_NEW, since they
 don't have enough state to actually run yet.  At this point you can set

docs/random/wtay/caps-negociation

@@ -1,3 +1,7 @@
+OUTDATED
+--------
+
+
 caps negotiation
 ================
 

docs/random/wtay/capsnego-cases

@@ -1,3 +1,6 @@
+OUTDATED
+--------
+
 
 pad has caps
 | pad has template

docs/random/wtay/eos-19012001

@@ -1,3 +1,6 @@
+OUTDATED
+--------
+
 EOS as implemented on Jan 21 2001:
 
 1) terminology

docs/random/wtay/eos2

@@ -1,3 +1,6 @@
+OUTDATED
+--------
+
 
 case 1) 
 

docs/random/wtay/eos3

@@ -1,3 +1,6 @@
+OUTDATED
+--------
+
 
 case 1) 
 

docs/random/wtay/eos4

@@ -1,3 +1,6 @@
+OUTDATED
+--------
+
 
 case 1) 
 

docs/random/wtay/eos5

@@ -1,3 +1,6 @@
+OUTDATED
+--------
+
 
 case 1) 
 

docs/random/wtay/events2

@@ -1,3 +1,6 @@
+INITIAL RAMBLINGS
+-----------------
+
 some random ramblings about the event system:
 
 Possible candidates for events

docs/random/wtay/messages

@@ -1,3 +1,7 @@
+OUTDATED
+--------
+
+
 problem 
 -------