docs/random/wtay/network-transp: Some old doc I had.

Original commit message from CVS:
* docs/random/wtay/network-transp:
Some old doc I had.

diff --git a/ChangeLog b/ChangeLog
index 66405d9..943eeb2 100644 (file)
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,5 +1,10 @@
 2005-07-27  Wim Taymans  <wim@fluendo.com>
 
+       * docs/random/wtay/network-transp:
+       Some old doc I had.
+
+2005-07-27  Wim Taymans  <wim@fluendo.com>
+
        * libs/gst/dataprotocol/dataprotocol.c: (gst_dp_packet_from_event),
        (gst_dp_event_from_packet):
        Fix serialization of seek events.

diff --git a/docs/random/wtay/network-transp b/docs/random/wtay/network-transp
new file mode 100644 (file)
index 0000000..6f209c4
--- /dev/null
+++ b/docs/random/wtay/network-transp
@@ -0,0 +1,48 @@
+Network Transparent elements
+----------------------------
+
+1) netbin
+
+   - exposes local shims and remote real elements.
+   - all shim pads can be connected to other shim
+     pads and operations are proxied to real elements.
+   - when the pads are not part of the same bin, network
+     transparent ghostpads are created to connect them.
+   - bin has host property to indicate where it should
+     run.
+
+2) netpipeline
+
+   - synchronizes different netbins, this means distributing
+     the same element base time to the remote bins.
+   - clocks master/slave is set up.
+
+3) netpad
+
+   - all pad operations are proxied to peer pad using
+     a network protocol, possibly selectable from RTP/TCP/....
+     Serialisation of buffers and events are to be considered
+     but also methods with their arguments. A generator would
+     not be too bad to automate this.
+   - the implementation would be fairly similar to the
+     ghostpad implementation.
+   - This includes event passing (bidirectional) and
+     data passing (unidirectional). Some events have to pass
+     in parallel with the datastream so the event path should
+     use a different connection.
+     
+4) GStreamer deamon
+
+   - each host has to run a deamon that listens for
+     commands and creates elements/pipelines and performs all
+     operations on the real pipeline.
+
+Other stuff
+-----------
+
+ - what about migrating elements from one host to another. This
+   would happen when an element is removed form a bin into another
+   bin. 
+
+ - do we have/need a fast protocol for stuff on the same machine or
+   will regular network connections work fine?