1 files changed, 0 insertions, 61 deletions
diff --git a/desiredata/src/iostream.txt b/desiredata/src/iostream.txt
deleted file mode 100644
index 5ed2bf25..00000000
--- a/desiredata/src/iostream.txt
+++ /dev/null
@@ -1,61 +0,0 @@
-------------------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)