Без ИОС. Скрипт читает файл с новостями, файл с шаблоном, параметрами, возможно, эти операции разделяются (а, возможно, работа происходит через SQL), в общем итоге составляется код HTML, который передается в stdout.

C ИОС управление получает скрипт ОС, который подгружает необходимую минимальную базу модулей, проделывает базовые операции: форматирует входящие параметры, устанавливает обработчик ошибок, устанавливается кешеризатор вывода. Затем управление передается нужному скрипту движка, который вызывает функции чтения и указывает, что читать (шаблон5, 20 последних новостей). В общем итоге получается HTML, который отправляется якобы в stdout. Ядро собирает заголовки, отправляет, что получилось у движка, и в случае наличия ошибок, могут быть отправлены данные и об этом. При наличии серьезных ошибок вызывается некое событие.

В общем, вот простой пример, как происходит совместная работа, и в чем разница между отсутствием и присутствием ИОС.

Функциональное наполнение ИОС

Из рассмотренной схемы мы уже начинаем представлять, что собственно должна делать ИОС. Давайте слегка пройдемся по функциям:

n  Перехват, обработка ввода/вывода, возможность управления этими процессами из движка (кеширование как один из видов обработки).

n  Обработка ошибок, предупреждений, исключений, максимум прозрачности для движка.

n  Функции СУБД. При отсутствии SQL должна быть альтернатива, предоставляющая способ работы с данными, избегая при этом работы с файловой системой.

n  Некоторые функции безопасности. Фильтры, конверторы.

n  Независимая от платформы база пользователей и удобный, гибкий интерфейс к ней.

n  Универсальная система логирования.

n  Система работы, создания и обработки событий и другие не менее значимые функции.

Зависимости

Давайте взглянем на примитивную схему ИОС: ИОС представляет собой несколько модулей. Будем исходить из того, что ОС написана на Perl. У ИОС не должно быть как такового ядра. Программист движка будет сам выбирать, что ему нужно. Отсюда каждая часть ИОС должна быть максимально независимой. Это действительно должно быть так, но связей и зависимостей не избежать. Обязательные зависимости должны быть решены жестко, подключением необходимых модулей, а остальные связи должны общаться через единую систему взаимодействия. Эта система обязательна для всех модулей. Я бы назвал ее системой событий. Именно события придают гибкость и возможность взаимодействия самых разных уровней решения задач.