Comments 8
В Plan9 взаимодействие с сервером сделано куда проще - через простой протокол 9p. И работать проще, и монструозных SDK не требуется (которые в случае динамических языков крайне неудобны).
Транспортный уровень для передачи пачек байтов (в т. ч. при файловых операциях), разумеется, будет проще, чем для передачи сложно структурированных данных, однако кажущееся облегчение от отсутствия монструозных SDK обернётся необходимостью всю обработку этих сырых данных делать уровнем выше - со всеми вытекающими. Здесь изначально подход "скажи мне, что делать, а не как" - требует больше информации на уровне API, чем при банальном "всё есть файл".
Кто мешает определить какой-нибудь протокол для передачи структурированных данных? JSON, BSON, MessagеPack - сотни их.
Что-то я перестал понимать, какую задачу Вы решаете. Если Вы хотите на базе JSON или подобного формата построить среду, в которой возможность любых программ взаимодействовать гарантируется по построению (на уровне возможности подмены любого узла любым совместимым узлом без необходимости менять что-либо в других узлах), то Вам так или иначе придётся строго определить правила взаимодействия. Можно не в виде "монструозного фреймворка", а в виде спецификации протокола взаимодействия, который каждая программа поддерживает самостоятельно, - количество информации получится одним и тем же (а вот работы программисту в случае с готовым фреймворком заметно убавится). В принципе, к описанной в статье системе ничего не мешает прикрутить интерфейс доступа по JSON (или даже заменить им основной канал), было бы желание.
Если же Вы просто хотите обмениваться какими-то данными в JSON или 9P, то это придумали до нас с Вами, но задач, ради которых затеяна описанная в статье разработка, это не решает.
Операционная система-суперприложение а-ля WeChat, без какой-либо возможности переносить существующие приложения без полного переписывания с самого фундамента? Попробовать можно, наверняка какую-то аудиторию любителей найдёт, но сомневаюсь в популярности этого подхода. Пользователю ведь пофигу на внутреннюю архитектуру, ему надо нажать иконку и открыть свои сообщения в мессенджере или видосик, популярность будет обеспечиваться только количеством нормально портированного софта на эту платформу.
Согласен, массовому пользователю это не надо - по крайней мере, не на системном уровне (хотя какие-то приложения на базе этой системы могут оказаться востребованы, но, опять же, всем будет пофиг на то, что у них под капотом). Точно так же какой-нибудь Linux долгое время был уделом гиков, но, тем не менее, сумел проложить путь подходу к разработке и распространению софта, отличным от принятых на тот момент в проприетарном мире. Если предложенная система сможет послужить чему-то подобному, пусть даже в качестве одного из камней пути, - будет здорово.
Что-то в процессе чтения сего опуса меня не покидало ощущение дежавю с нафталином.
То COM, то CLR, то SOAP... Притом многое почему-то взято с кладбища технологий.
Кстати, этот самый ввод-вывод хоть асинхронным предполагается-то?
CLR вполне себе активно используется - на дотнет много разработки идёт. SOAPы-RESTы тоже, вроде, умирать не собираются. COM... Опять же, трансформировался в ActiveX, на котором пусть не так много чего-то пишется сейчас, но и от написанного вряд ли получится так сразу избавиться. Из более свежего можно вспомнить какой-нибудь GRPC. Но да, я и не утверждаю, что сам подход с ООП-RPC я лично придумал - было бы странно, если бы это не оказалось похоже на что-то из уже существующего.
Разумеется, вызовы могут быть и синхронными, и асинхронными. В спойлерах есть примеры кода и того, и другого.
ОС «Сивелькирия»: архитектура