AP
Транзит плоущ, да
Size: a a a
2020 November 13
AP
Но он всё равно байтики в base64 передаёт
AP
Можно сделать формат "перемежающимся" с делением пакетов на EDN и "блоб байтов длины n"
AP
Причём описание блоба передавать в EDN же. Типа
{:type :blob :size 1204 :meta "MPEG-frame"}....1204байтика....AP
Само наличие discoverable заголовков поможет и в отладке
AP
Таким макаром можно передать рекорд с блобами в виде "заголовок со ссылками на последующие блобы"+"блобы подряд"
AP
{:type :user :name "Bob" :photo :&2 :avatar :&1}
{:type :blob :size 7074}######
{:type :blob :size 4040}#######AP
Такое разделение со ссылками позволит в том числе и рекорды вложенные передавать, выделив вложенные сущности в отдельные пакеты
AP
Это всё мои дилетантски-диванные рассуждения, может и есть что-то готовое, не обессудьте
KC
Ну тут шашечки или ехать) строки как формат передачи или бинари для всего имхо. Едн ридер для бинарных данных написать не сложно будет
AP
Бинари для всего — норм. Можно просто EDN обинарить
AP
И подшивать бинарники при декодировании так, чтобы можно было получить EDN верхнего уровня, а по нему достать блобы из того же пакета
JS
AP
Круче в плане количества нытья, чем в статейке по моей ссылке выше, мало что может быть :)
AP
Там автор и файловую систему ругает, например — за то, что это не объектное хранилище
AP
И что вообще есть файлы данных, а есть конфиги в каких-то форматах. Вместо того, чтобы программе сразу ходить в БД и за настройками, и за входом, и данные туда же класть. И логи, и вообще всё
AP
IPC тоже предполагается завязать на эту "БД".
AP
Статья хорошая прям. Как книжка по интерфейсам от Раскина — навевает светлую грусть и понимание, что такого не будет никогда
AP
(Раскина рекомендуют дизайнерам интерфейсов читать не реже, чем программистам рекомендуют SICP. В итоге джеффовы идеи никто не применяет, потому что они не про продажи, а про удобство в долгосрочной перспективе)
Y
вот тут ещё плач о unix way https://habr.com/ru/post/321652/
Да Unix Way — это вообще религия