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