diff options
Diffstat (limited to 'desiredata/src/iostream.txt')
-rw-r--r-- | desiredata/src/iostream.txt | 61 |
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) |