Added some ramblings about a messaging system idea..BRANCH-BUILD1-200112061-ROOT

Original commit message from CVS:
Added some ramblings about a messaging system idea..

1 files changed, 131 insertions, 0 deletions

diff --git a/docs/random/wtay/messages b/docs/random/wtay/messages
new file mode 100644
index 000000000..9b12c3c3b
--- /dev/null
+++ b/docs/random/wtay/messages
@@ -0,0 +1,131 @@
+problem 
+-------
+
+Since gstreamer uses a hierarchical pipeline layout individual elements
+can be inside N levels of containers (bins). Elements can also produce
+interesting information for the user app or for its parent.
+
+Consider the mp3parse element that could detect id3 tags in the stream.
+One way to let the app know about those tags is by emitting a signal. The
+problem with this signal is that the app has to perform a g_signal_connect
+on this element. This might not always be possible/feasable because
+the APP might not know about the mp3parse element (eg. an autoplugged
+pipeline or a compound object). The app could instrospect each element
+in the pipeline and look for known properties/signals to connect to,
+but that looks a bit ugly IMO.
+
+Signal proxying is also not very feasable because signals are tied to
+class instances.
+
+let's take the following use case:
+
+ - the user autoplugs an mpeg1 pipeline
+
+ - the autoplugged pipeline most likely contains an mpegdemuxer, an mp3
+   decoder, mpegdecoder etc.
+
+ - the mpegdemuxer knows the (average) bitrate of the stream.
+
+ - the mpegdecoder knows the framerate of the stream
+
+ - the mp3 decoder has some neat stuff too (bitrate, layer etc..)
+
+how are we going to get all those properties to the app? each element
+could fire a signal with the data. It the app were able to connect to
+every signal in each element this would work somewhat.
+
+
+Requirements 
+------------
+
+The application can listen to an abritrary bin in the pipeline to collect
+information about that bins children. The app can listen on the top
+level bin to collect all of the elements messages.
+
+The data sent out by the elements must not be limited to a fixed set of
+messages; it must be extensible.
+
+
+proposed solution 
+-----------------
+
+We propose another way of propagating these element messages to the
+application.
+
+An element can send a message to its parent using a
+gst_element_send_message (element, message). The message would be of type
+GstMessage and would be similar to a GstEvent type (maybe even the same).
+
+The message would contain GstProps, which can be anything (a string, an
+int, a range etc..). It would also contain the originator of the message.
+
+The parent would just simply accept the message (and do something with it)
+or the default handler would just forward the message to its parent etc..
+
+The message would bubble up the pipeline. When an element doesn't have
+a parent, the message is converted to a GSignal. The signal ("message")
+would just forward the message to any listening apps.
+
+The app can then use the originator field of the message to find out
+where it came from, possibly using the elementfactories klass field to
+find out what type of plugin created this message.
+
+For an autoplugged mpeg1 pipeline the following messages could be
+signalled to the app:
+
+element klass        element      property      value
+                     name
+
+stream/mpeg/demuxer: (mpegdemux) "bitrate",   GST_PROPS_INT (1000000)
+stream/mpeg/demuxer: (mpegdemux) "type",      GST_PROPS_STRING ("mpeg1") 
+video/mpeg/decoder:  (mpeg2dec)  "type",      GST_PROPS_STRING ("mpeg1") 
+video/mpeg/decoder:  (mpeg2dec)  "frame_rate",GST_PROPS_INT (25) 
+video/mpeg/decoder:  (mpeg2dec)  "size",      GST_PROPS_LIST (
+                                                 GST_PROPS_INT (320), 
+					         GST_PROPS_INT (200)
+					       ) 
+audio/mp3/decoder:   (mad)	 "layer",     GST_PROPS_INT (2) 
+audio/mp3/decoder:   (mad)	 "bitrate",   GST_PROPS_INT (128000) 
+audio/mp3/decoder:   (mad)	 "channels",  GST_PROPS_INT (2)
+
+other possibilities:
+
+video/render/X:     (xvideosink) "frames_dropped", GST_PROPS_INT (4)
+video/render/X:     (xvideosink) "frames_shown",   GST_PROPS_INT (254) 
+video/mpeg/decoder: (mpeg2dec)	 "frames_dropped", GST_PROPS_INT (2) 
+video/avi/demuxer:  (avidemux)   "codec",          GST_PROPS_FOURCC ("DIVX")
+
+or
+
+video/mpeg/decoder: (mpeg2dec)  "state_changed", GST_PROPS_INT (GST_STATE_PAUSED)
+
+or even
+
+audio/render/oss:    (osssink)	"master_clock", GST_PROPS_OBJECT (osssink_clock)
+....
+
+or even even:
+
+input/file/filesrc:  (filesrc)	"here_i_am", GST_PROPS_STRING ("alive and kicking")
+
+
+With standard naming conventions for the element klass type and the
+messages ids, the player can easily create an info dialog to show various
+properties of the stream.
+
+The benefits are that we don't need to define N-thousand methods on
+elements, the messages can be anything and we don't have to use the
+heavyweight GObject signals in the core library.
+
+
+what about?  
+-----------
+
+- Threads? do we queue events and let the top half collect the messages
+  or do we send them to the app in the thread context?
+
+- do we need a similar system for core functionalities (clocks, states,
+  ...) or do we define methods for those?
+
+
+