Опишем ещё несколько принципов построения архитектуры операционной системы «Сивелькирия». Они вторичны по отношению к озвученным ранее, но, тем не менее, достаточно важны.
- Существует специальный сетевой протокол для связи между любыми устройствами, на которых выполняется операционная система «Сивелькирия». Все данные, доступные через интерфейсы, определённые в операционной системе, могут быть сериализованы и переданы по этому протоколу. В этом случае на втором конце линии операционной системой создаётся объект-прокси, все манипуляции с которым передаются на породившую оригинальный объект машину и там обрабатываются. Данная операция абсолютно прозрачна для потребителя объекта и не требует создания отдельных протоколов под каждую задачу. Таким образом возможно, например, при помощи программы просмотра изображений, запущенной на одном компьютере, просматривать файлы, находящиеся на другом, загружаемые на другое устройство по сети или создаваемые динамически выполняемыми на нём программами. Кроме того, данные могут пробрасываться сквозь устройства; так, данные с умных часов, соединённых со смартфоном по каналу Bluetooth, могут далее по WiFi передаваться на компьютер, не имеющий интерфейса Bluetooth, с полным сохранением контекста без необходимости дополнительного программирования. Поскольку все интерфейсы данных имеют чётко прописанное назначение, при передаче данных ОС может применять соответствующие обработки (например, при передаче данных видеозвонка пропущенные пакеты теряются, чтобы избежать нарастания задержки, но при передаче текста подобное выпадение пакетов недопустимо).
- Интерфейсы данных могут использовать друг друга, способствуя повторному использованию кода. Например, интерфейс «Данные об изображении» будет включать элемент типа «Размеры изображения».
- Интерфейсы данных могут наследоваться друг от друга, отражая переход от общего случая к частному. Например, интерфейсы «Растровое изображение» и «Векторное изображение» наследуются от интерфейса «Изображение». В контекстах, где тип изображения не важен, может быть использован более общий интерфейс.
- Интерфейсы даных могут реализовывать другие интерфейсы просто по определению. Например, интерфейс «Содержимое директории» сам по себе содержит данные в специальном представлении (количество элементов, имя и тип каждого элемента, размер, описание и так далее), однако эти данные могут быть извлечены из него в табличном формате через интерфейс «Таблица с данными» для вставки в табличный процессор. Каждому модулю, реализующему интерфейс «Содержимое директории», не нужно заботиться о конвертации данных к интерфейсу «Таблица с данными», так как она осуществляется операционной системой (или вызываемым ею специализированным модулем) на уровне поддержки данных интерфейсов. Это позволяет использовать объекты данных в любых применимых контекстах.
- При обмене данными интерфейсы сохраняют необходимую сопутствующую информацию, такую, как описание и происхождение измеряемых параметров и физические размерности, валюты и так далее. Например, размер изображения, заданный в пикселах, не смешивается с размером экрана, заданным в миллиметрах. Приложение-переводчик гарантированно получит данные о языке, на котором выведено переданное в него слово, что позволит избежать неоднозначности.
- Модульная архитектура и резервирование функций управления ресурсами системы (потоки и т. п.) за операционной системой позволяют простой заменой соответствующих модулей существенно менять поведение системы. Так, для решения узкоспециализированных задач система может быть укомплектована модулями планировки заданий, реализующими стратегию операционной системы реального времени, тогда как для большинства приложений будет использоваться событие-ориентированный подход. Данные изменения не приведут к необходимости переписывания всех прикладных модулей.
- На каждой аппаратной (или программной, см. далее) платформе, на которой может быть запущена ОС «Сивелькирия», доступны модули виртуальных машин, позволяющие запускать модули, скомпилированные для других поддерживаемых платформ. Таким образом, модуль, доступный под одной платформой, может быть запущен на любой другой платформе, хоть и с потерей производительности.
- Все данные, доступные через интерфейс, доступны через его основные элементы. Использование дополнительной информации (коллекции именованных свойств, расширения и т. п.) не допускается. Способа определить тип объекта и его происхождение по его интерфейсу не существует. Таким образом, создание проприетарных платформ обмена данными внутри операционной системы невозможно, и все данные будут доступны любому контексту.
- Файловая система ориентирована на хранение объектов. В этом смысле байтовый массив, соответствующий файлу, является лишь одним из частных случаев такого объекта. Объекты в файловой системе могут хранить произвольную информацию — например, для поддержки кэша таких часто используемых данных, как миниатюра изображения или ссылка на кодек, используемый для его чтения. Ссылки между объектами являются одной из форм представления данных и замещают собой абсолютные и относительные пути. Таким образом достигается совместимость не только во время выполнения, но и на уровне хранимой информации: например, любой обработчик событий может использовать (и хранить в конфигурации) триггер любого типа, установленного в системе, просто сохранив ссылку на соответствующий объект.
- Произвольное сканирование файловой системы модулями запрещено, кроме особых случаев: для реакции на действия пользователя или для совместимости с другими системами. Доступ возможен только к тем объектам, на которые у модуля существуют ссылки.
- В большинстве случаев разницы между интерфейсом объекта, загруженного в память, и объекта, сохранённого на диск, нет — они рассматриваются как один. Абстрактный доступ к «собственно файлу» как набору байт осуществляется только модулем, который отвечает за отображение файла на некоторый объект (интерфейс данных). Вместо абстрактной работы с файлами программы работают с объектами, которые затем могут обрабатываться другими программами безотносительно формата хранения. Это не ограничивает возможностей доступа к содержимому файла в текстовом или бинарном представлении по мере необходимости.
- Данные на диске поддерживают дополнительные по сравнению с традиционными файловыми системами операции: перемещение частей содержимого, транзакции, версионность и так далее. Версии файла, созданные одной программой, видны всем другим программам в удобном представлении. Если во время записи файла произошёл сбой, доступны и его состояние до перезаписи, и недописанная новая версия, причём отдельных усилий со стороны программиста это не требует.
- Для пользователя поиск объектов на диске осуществляется не по расположению в иерархической структуре, а по признакам: типу, имени, категории, тегам, метаинформации, связям с людьми и объектами реального мира, связям с другими объектами, хронологии, способу доступа, происхождению и так далее. Организация хранения оказывается вторичной по отношению к классификации данных пользователем: например, пользователь может указать, что программы хранятся на быстром SSD, фотографии — на RAID-массиве с защитой от потери данных, личные записи — в облаке, а рабочие файлы автоматически дублируются между всеми устройствами. Пользователь может использовать предустановленную систему классификации объектов или настроить её на собственный вкус.
- Настройка вида и способа представления графических программ осуществляется централизованно. Глобальные настройки вида затрагивают все пользовательские интерфейсы (но могут быть уточнены для конкретных контекстов). Например, пользователь может выбирать, насколько подробная техническая информация предоставляется ему по умолчанию (данные, интересующие опытного администратора, будут лишь мешать творческому работнику), используется ли классический стиль меню или значки (удобство для конкретного пользователя определяется типом восприятия и состоянием здоровья), соблюдается ли общая цветовая палитра для всех приложений, представляются ли данные в графическом или текстовом виде, используется ли при редактировании форматированного текста WYSIWYG-подход или разметка на специальном языке, и так далее. Каждый модуль не обязан поддерживать все возможные варианты, но информация о поддержке конкретных режимов доступна в репозитории.
- С точки зрения операционной системы всё является объектами: и окно с его текущим состоянием, и документ, хранимый на диске. Как документ, так и окно могут быть сериализованы, сохранены, переданы на другое устройство и восстановлены операционной системой в любой момент без предупреждения (хотя смысл сериализации и десериализации может различаться для разных типов объекта). Например, в домашней сети пользователь может просмотреть окно, открытое на настольном компьютере, с мобильного телефона. Чтобы способстовать этому, модули, реализующие пользовательский интерфейс, могут адаптироваться к изменениям в типе устройства (разрешению и физическому размеру экрана, способу ввода и т. п.).
- Существуют интерфейсы, соответствующие не конкретным объектам прикладной области, а парадигмам работы с ними. Например, интерфейс «Длительная операция» должен быть реализован любой операцией, занимающей значимое (например, от 1 секунды) время. Реализация этого интерфейса означает, что, независимо от природы операции, она может контролироваться из любого контекста: операции можно ставить в очередь, назначать обработчики (например, отключение устройства) их завершению, прерывать, просматривать статус, уровень прогресса и оставшееся время, выводить информацию о статусе важных операций в легко доступном месте, и так далее.
- Данные, имеющие схожую природу, группируются операционной системой (причём, возможно, в рамках более чем одного устройства). Например, все программы используют общую систему логирования — в этом случае сведение логов в одну таблицу, например, при отслеживании сетевого сбоя, становится тривиальной задачей. Другой пример — это список запросов от программ на обслуживание (обновление, разрешение конфликтов и т. п.): сообщения, которые не являются экстренными, будут дожидаться момента, когда пользователю будет удобно их обработать, в соответствующем месте. Программы обмена сообщениями группируют переписку с каждым человеком в одном месте независимо от канала, по которому те были получены. Уведомления о событиях и публикациях, на которые пользователь был подписан, собираются в общем месте (аналоге «стены» в социальной сети). Рекомендации группируются здесь же, но с меньшим приоритетом. Способы управления подписками (например, немедленное уведомление о материалах конкретного автора) настраиваются в общем виде, независимо от поддержки таких настроек конкретным поставщиком содержимого (социальной сетью, видеохостингом и т. п.). Программы, отправляющие данные в общие места, не имеют доступа к данным друг друга. Таким образом, при использовании некоторой функции (обмен сообщениями, видеозвонок, просмотр уведомлений и т. п.) пользователю не нужно задумываться о том, какая конкретная программа реализует её.