Update of /cvsroot/pure-data/pd/src In directory sc8-pr-cvs1.sourceforge.net:/tmp/cvs-serv10157

Added Files: Tag: desiredata iostream.txt Log Message: separated this from TODO

--- NEW FILE: iostream.txt --- ------------------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)