История изменений
Исправление thegoldone, (текущая версия) :
Т.е. если перефразировать:
SysVinit был кривой-косой, но он работал, худо-бедно договорились. Теперь сделают новую систему инициализации с учетом прошлых ошибок, и переведут всё на нее, закопав SysVinit, как раньше закопали System III, upstart и прочий хлам.
Невозможно без практического опыта и набитых шишек сделать систему инициализации нормально. И даже со второго. Пока ее не начали все массово использовать - не было понятно, что конкретно реализовано плохо и чего не хватает.
А протокол ты где возьмешь?
Это application level. Способ связи свой протокол навязывать не должен. Просто предоставлять двунаправленное соединение как файл. Приложения уже между собой договариваться какой там протокол и прочее.
Его все еще нужно разработать и стандартизировать, причем с последним будет больше всего проблем, потому что протокол системной шины должен устраивать разработчиков большинства компонентов ОС.
Да это всё не имеет отношения к способу связи. Возьмём простой пример
connect(remote_url) -> connection
// work with connection
close(connection)
Всё. Единственное, что должен обеспечивать способ связи – это разрешать remote_url и соединять две точки.
Причём не обязательно remote_url должен иметь какой-то единый однозначный эталонный вид. Он может разрешаться по разному. В зависимости от префикса (схемы) и так далее.
А протокол обмена – этим занимаются приложения, когда уже установлено подключение.
То же касается и всяких подписок. Широковещательных сообщений. Которые не являются частью способа связи. Нужен брокер сообщений – отдельное приложение. Со своим протоколом, если нужно.
Получается, что при проектировании очередного костыля не закладывается ничего на лёгкость его демонтажа в последствии. Если всё так как Вы говорите, то демонтаж неизбежен. И должен закладываться при проектировании. Иначе и быть не может.
А этому неплохо способствует т.н. the UNIX way. Когда одно приложение (система) не впитывает в себя всё вокруг.
Исходная версия thegoldone, :
Т.е. если перефразировать:
SysVinit был кривой-косой, но он работал, худо-бедно договорились. Теперь сделают новую систему инициализации с учетом прошлых ошибок, и переведут всё на нее, закопав SysVinit, как раньше закопали System III, upstart и прочий хлам.
Невозможно без практического опыта и набитых шишек сделать систему инициализации нормально. И даже со второго. Пока ее не начали все массово использовать - не было понятно, что конкретно реализовано плохо и чего не хватает.
А протокол ты где возьмешь?
Это application level. Способ связи свой протокол навязывать не должен. Просто предоставлять двунаправленное соединение как файл. Приложения уже между собой договариваться какой там протокол и прочее.
Его все еще нужно разработать и стандартизировать, причем с последним будет больше всего проблем, потому что протокол системной шины должен устраивать разработчиков большинства компонентов ОС.
Да это всё не имеет отношения к способу связи. Возьмём простой пример
connect(remote_url) -> connection
// work with connection
close(connection)
Всё. Единственное, что должен обеспечивать способ связи – это разрешать remote_url и соединять две точки.
Причём не обязательно remote_url должен иметь какой-то единый однозначный эталонный вид. Он может разрешаться по разному. В зависимости от префикса (схемы) и так далее.
А протокол обмена – этим занимаются приложения, когда уже установлено подключение.
То же касается и всяких подписок. Широковещательных сообщений. Которые не являются частью способа связи. Нужен брокер сообщений – отдельное приложение. Со своим протоколом, если нужно.
Получается, что при проектировании очередного костыля не закладывается ничего не лёгкость его демонтажа в последствии. Если всё так как Вы говорите, то демонтаж неизбежен. И должен закладываться при проектировании. Иначе и быть не может.
А этому неплохо способствует т.н. the UNIX way. Когда одно приложение (система) не впитывает в себя всё вокруг.