Низкоуровневые связи между программами

Современные операционные системы предлагают возможности для обмена данными между программами, однако эти возможности зачастую оказываются низкоуровневыми, то есть относящимися к деталям реализации, а не к предметной области. Такие примитивы, как файлы, блокировки, каналы, мютексы, сокеты, общая память и т. д. позволяют наладить взаимодействие каждой пары программ путём их обоюдной модификации, однако этого слишком мало для организации связи между всеми программами в масштабах компьютера или сети: легко посчитать, что для интеграции двух программ нужно внести 2 правки, тогда как для независимой интеграции десятка программ — уже 90 правок.

Популярен способ расширения программ через плаг-ины, однако те пишутся под API конкретных версий конкретных программ, хотя их функциональность зачастую вполне востребована в рамках других схожих решений. Например, плаг-ин для почтовой программы Mozilla Thunderbird, выдающий предупреждение при попытке отправить письмо с личного адреса в корпоративный домен, по смыслу будет полезен в составе любой другой почтовой программы, однако из-за несовместимости API область его применимости ограничена.

Нередка ситуация, когда одна программа для взаимодействия с другой читает созданные ею конфигурационные файлы или записи в системном реестре. При этом возникает зависимость между версиями этих программ (через формат и расположение конфигурационного файла). Например, при выходе новой версии среды Visual Studio требуется обновление версии Cmake, без которого использование нового компилятора из проектов cmake невозможно. В Linux-системах подобный подход часто принимает формы бедствия, когда одна программа генерирует конфигурацию для другой программы, и раскрутить эту цепочку без соответствующего опыта оказывается весьма непросто.

Организация взаимодействия процессов и окон также излишне сильно зависит от того, какие конкретно программы используются. Взаимодействие по сети подразумевает наличие некоторого протокола, который почти всегда различается для различных систем, даже если те решают внешне схожие задачи.

«Сивелькирия» предлагает не прикручивать совместимость задним числом, а начать с выстраивания всех программ на базе одних и тех же понятий. Вместо того, чтобы составлять словарь для каждой пары языков, можно изначально договориться об использовании общего, эволюционирующего диалекта (не ограничивая, впрочем, используемых технологий и языков программирования). К примеру, любая программа записи видео будет в таком случае совместима с любой моделью камеры и форматом потока просто по определению, включая поддержку сетевых камер без дополнительных трудозатрат со стороны программиста. Плаг-ин, решающий конкретную задачу (например, добавляющий способ обработки почты), будет совместим с любой почтовой программой. Системному администратору не придётся долго выбирать решение, анализируя поддерживаемые им возможности, поскольку все решения поддерживают любые дополнения и способы обработки почты просто по построению. Сглаживание различий между версиями программ при взаимодействии берёт на себя операционная система, а взаимодействие ведётся не на уровне конкретных программ, но абстрактно, на уровне типов данных.