OberonCore

В файл писать по одному байту тоже не очень эффективно.

Ну, мне казалось, про что такое буфер знает каждый программер

Ув. Trurl меня опередил своим намёком.

+Так над чем предлагается сделать маппер: над буфером или над сетевым интерфейсом?

Буфер -- это деталь реализации маппера над сетевым интерфейсом.

Вы говорили о CommStreams.Stream и маппере навроде Stores.Reader/Writer.

Маппер а-ля Stores.Reader/Writer возможен над буфером, но невозможен над CommStreams.Stream.

Простой пример. Задумайтесь как реализовать над CommStreams.Stream.ReadBytes процедуру Stores.Reader.ReadReal. Процедуре ReadReal нужны восемь байтов, но на момент её вызова по сети может быть получено меньшее количество байтов. Каково должно быть её поведение в этом случае? По ассерту завалить программу?

Чтобы не ломать голову, десериализации логично подвергать целое сообщение.

Поэтому поверх сетевого интерфейса (CommStreams.Stream) надо реализовать другой интерфейс -- специального транспортного протокола уже для целых сообщений. Этот протокол обеспечивает транспортировку неделимых массивов байтов. Зная только их размер он не знает как их десериализовывать.

Далее (в стеке протоколов) выстраивается ещё один уровень абстракции -- объектный. Этот интерфейс заведует сериализацией и десериализацией объектов в массивы байтов и обратно. На входе у него очередь отправляемых объектов, на выходе -- очередь доставленных объектов.

Маппер а-ля Stores.Reader/Writer засунут в механизм сериализации/десериализации этого последнего объектного интерфейса (и реализован этот маппер над буфером).

Да я не против. В контексте моего высказывания это всё детали реализации. Семечки для столь крутых мастеров

Вопрос к .NET-щикам: а там какая-то абстракция для потокового ввода-вывода путёвая сделана?

Это только переносит проблему в другое место.

Есть ли какие-то смысловые нюансы в терминах stream, channel, pipe - или выбор любого из них - дело вкуса?

О. Есть ещё: link

О. Channel, оказывается, применяется для односторонних каналов.

Ну в принципе есть классы StreamReader/StreamWriter, которые используются для записи/чтения файлов, связи через TCPClient/TCPServer и прочего.
В общем-то вроде работает, и даже вполне юзабельно (ну хотя тут на разные вкусы не угодишь, конечно).
Правда, сериализация/десериализация данных в бинарный вид по моим тестам оказалась медленнее, чем работа с plain text-файлами, страшно представить, как тормознуто будет это с XML-сериализацией работать...

stream -- поток для работы с файлами в основном, а также для эмуляции ленивых списков (потоки данных) в энергичных языках.

channel -- для связи между процессами, работает как очередь, накапливающая сообщения.

pipe -- конвейер из программ: одна отработала, выдала данные для другой, та для третьей и т.д.

Меня интересует не то, для чего используется в языках/ОС; а нюансы самих слов. В технике.

Тогда примерно так:
Stream обозначает процесс движения.
Channel задаёт направление движения.
Pipe - механизм объединения (согласования) Channel для формирования единого пути, который на уровне выше, где pipe не виден, выглядит (или может выглядеть) как Channel.

Ну там есть как бы универсальная "царь-машина" System.IO.Stream с кучей наследников. Я ей не пользуюсь, написал своё конкретное (в смысле не универсальное).

Что-то я такое смотрел... Там полная хреновня с перегрузкой вывода разных типов? Как С++-потоки?

Такой обескураживающий вопрос...
Что значит -- "полная хреновня"?
А как Вы-то хотели? Так же как у Вас в Блекбоксе -- для каждого типа отдельная процедура? Да нафик надо...

Это два разных слоя по определению - нетипизированный поток и мэппинг типов в байты.
(Например, сколько разных способов вывести текст? В какой кодировке? И т.п.)

Или у Шарпа-Явы проблемы с работой с нетипизированными данными? Приходится прошивать маппинг на самый нижний уровень, в "методы" элементарных типов? Ну так это родовые проблемы, заложенные в язык.

Какая может быть вменяемая работа с нетипизированными данными? Проблемы с ними быть обязаны, ибо нефиг заниматься такими вещами, не BCPL всё-таки.

Представьте себе, очень даже может быть

А если я Вам скажу, что может быть ещё и безопасной, Вы вообще в осадок выпадете?

(понимая под безопасностью, например, в КП - неиспользование SYSTEM или аналогичных средств, могущих нарушить целостность памяти).

Подсказка: сочетание абстракции типа Files.File (двоичный байтовый поток), метапрограммирования и наличия в языке нормальных нединамических структур данных.