reorganized

svn path=/trunk/; revision=9400

1 files changed, 61 insertions, 0 deletions

diff --git a/desiredata/src/iostream.txt b/desiredata/src/iostream.txt
new file mode 100644
index 00000000..5ed2bf25
--- /dev/null
+++ b/desiredata/src/iostream.txt
@@ -0,0 +1,61 @@
+------------------8<--------cut-here--------8<------------------
+Dec 26 2005
+
+1.1. a OutByteStream object is one that accepts those messages on inlet 0:
+  * float: seen as a byte (0..255)
+  * list of floats: seen as a sequence of float messages.
+  * symbol: seen as a \0-terminated string.
+  * bang: forces buffer-flushing if there's a buffer.
+
+1.2. a OutByteStream object may also optionally respond to string
+     messages, in my dreams. However, in the meanwhile, it may be more
+     appropriate to use a new special C function that accepts a pair of
+     int and const char * (\0 is not honored: the int specifies the size).
+     This is so that there is no speed disincentive to switch to decoupled
+     I/O objects.
+
+2.1. an InByteStream object is one that accepts those messages on inlet 0:
+  * bang: polls for more input (unlimited size).
+  * float: treated as int. polls for at most N bytes.
+  * auto 0: requires bang for getting more input.
+  * auto 1: uses a t_clock (hidden [metro]) for auto-polling.
+
+2.2. an InByteStream may produce those messages:
+  * float: seen as a byte (0..255)
+  * list of floats: seen as a sequence of float messages.
+
+and when in "auto 0" mode, it will only send it when receiving a bang or
+float.
+
+2.2. an InByteStream object may also optionally produce string
+     messages, in my dreams, etc. What would the C function(s) look like
+     in this case?
+
+3. an IOByteStream object is just an InByteStream object and an
+OutByteStream object at the same time. There is no conflict between the
+two.
+
+4. there would be object classes called [tcp] and [udp] which would be
+   InputOutputStream objects (supporting in, out and bidi connections).
+   They would also respond to "connect" and "disconnect" (or maybe "open"
+   and "close" instead) and also "listen" for enabling server mode.
+
+5. there would be an object class called [fudiin] which would be an
+OutByteStream and [fudiout] which would be an InByteStream. Thus, to get a
+bidirectional [netsend] [netreceive], use this triad:
+
+ |
+[fudiout]
+ |
+[tcp]
+ |
+[fudiin]
+ |
+
+Leaving out the first or the last object gives you [netsend] and
+[netreceive] respectively.
+
+6. a [tcp]<->[fudiin] pair can replace the server-side of the GUI
+   connection as long as the [tcp] object supports char* input as
+   suggested in part 1.2. (if the rest of this proposal is not
+   implemented, then use a slightly modified [netreceive] instead)