This page is part of the web mail archives of SRFI 56 from before July 7th, 2015. The new archives for SRFI 56 contain all messages, not just those from before July 7th, 2015.
Dear SRFI-56 members,
> If people wish to have the means of ensuring a binary port in
> portable way, I'd rather have open-binary-{input|output}-file,
> which can be easily implemented on both (a) implementations that
> doesn't distinguish binary/character port, and (b) implementations
> that requires binary/character distinction at port creation.
I have a different opinion about this open-binary-input|output-file.
What about the following existing constructs:
open-input|output-string
open-input|output-cstring (bigloo)
open-input|output-pipe
open-input|output-socket
(values input-port output-port) run-process command (mzscheme?)
or even (my srfi proposal on SHM)
open-input|output-shm
The functions in SFRI-56 are saying enough about the binary
character of the primitives.
I think, one should not interfere with the creative process of
software engineers by limiting the possibilities of the language
at hand.
For instance:
1. To communicate with PostgreSQL both text- and binary
input/output are neccessary. Text for the normal SQL handling,
binary for the COPY-IN constructs for blobs.
2. In the protocol of many instant messengers, both text and
binary protocols are mixed. To communicate a ZIP file, binary
protocol is used, to communicate (meta) information, text
protocol is used.
Let the software engineer decide how to handle the "markup" of
his/hers protocols. If he/she wants to mix clarity of text with
performance of binary protocols. Let him/her do so.
--
Hans Oesterholt-Dijkema