[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: binary vs non-binary ports
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