From 8dbec761cf858ea65900c8a094599857208d8c3a Mon Sep 17 00:00:00 2001 From: "N.N." Date: Tue, 5 Jan 2010 22:49:36 +0000 Subject: svn path=/trunk/; revision=12907 --- desiredata/src/iostream.txt | 61 --------------------------------------------- 1 file changed, 61 deletions(-) delete mode 100644 desiredata/src/iostream.txt (limited to 'desiredata/src/iostream.txt') 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) -- cgit v1.2.1