Ну экспортироваться будут все перменные, это понятно. А вот какие переменные импортировать и откуда - вот в чем вопрос   


Не факт, сильно зависит от предметной области. Мы о ней пока ничего не знаем, может поделитесь сокровенными знаниями (если не секрет) ?

Ух как далеко заходим...  Что и откуда импортировать - это вопрос уже к пользователю фреймворка. Пока я хочу этот вопрос (временно) закрыть путем явного импортирования всех данных, причем импорт происходит не по желанию потребителя/клиента, а по мнению производителя/сервера - это позволит потом накладывать ограничения на выдаваемые данные. Т.е. клиент подписывается на все, а сервер ему это "все" выдает с учетом своего мнения, что на самом деле нужно выдавать.


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

Все импортировать не получится. Для импорта любой переменной в клиенте должен быть инстанс соответствующего объекта (SharedVarRO), а это значит, что максимальное количество импортируемых объектов жестко задается самим клиентом, и не зависит от конфигурации сети


Это слишком общее описание. Под такое может подойди все, что угодно. Набор вручную заданных конфигов на каждом узле это обеспечит, но такое решение совершенно не manageable
 

Я не совсем корректно выразился - да, клиент определяет что бы он хотел получить путем создание инстансов SharedVarRO, а сервер определяет, что он ему может дать - т.е. возможна ситуация, когда клиент какие-то данные вообще не получит и инстанс SharedVarRO будет возвращаеть null вместо значения. Поскольку приложение специализированные, то количество инстансов будет задаваться на этапе разработки - определение структуры данных в приложении в рантайме вещь интересная, конечно, но это слишком накладно будет. Т.е. задача попроще стоит - на этапе разработки уже известно какие данные и от каких датчиков мы будет получать конкретный узел. Остальные узлы подписываются на показания нужных им датчиков - т.е. опять же на этапе компиляции задаются нужные инстансы. Т.о. получается, что структуру данных всей сети мы определяем в компайлтайме (не совсем уж жестко определяем - точнее сказать очерчиваем границы этой структуры), а уже в рантайме происходит заполнение этой структуры.


Согласен, это не удобно. Но возможны ситуации, когда из-за отсутствия каналов связи сеть будет распадаться на изолированные островки - если завести управление на единый сервер, то один островок останется управляемым, а остальные?

Честно говоря, я всей проблемы полностью еще сам пока не представляю - в реале подобные задачи уже десятки лет решаются обычными АСУ, которые подразумевают жесткую иерархию, и смотря как они решаются (а решаются не очень) и возникла мысль сделать все по другому -  изменить сам подход к решению проблемы. А раз подход новый, то и вопросов куча у самого.

Угу


В случае автоматичеси назначаемого сервера (в сегменте сети), в каждом островке образуется по серверу. Остается только предусмотреть средства, что бы эти сервера не передрались когда соединения между островками восстановится
  

В принципе можно начать и с конфигов, и в дальнейшем это развить.

Это было бы классно, но за неимением ресурсов лучше так: