vitus_wagner (![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png)
vitus_wagner) wrote2007-02-17 02:41 pm
vitus_wagner) wrote2007-02-17 02:41 pm
Entry tags:
И всё-таки Экслер в чём-то прав
Когда утверждает что не понимает как замена американского проприетарного софта на американский же OpenSource приведет к повышению информационной безопасности.
Проблема, конечно, не в том, американский софт, финский или китайский. Проблема в том, понимает пользователь как он работает или нет.
В последнее время OpenSource, стремясь потакать привычкам пользователей (и, что самое ужасное, разработчиков), воспитанных на проприетарном софте, развивается куда-то не туда. Появляются нетривиальные API, сложные межкомпонентные взаимодействия и т.д.
Вот разбираюсь сейчас с устройством DBUS. По идее, мысль крайне здравая - создать системную шину сообщений через которую смогут эффективно общаться процессы, не имеющие общего предка. Ввести на ней стандарное иерархическое пространство имен, чтобы можно было легко настроить фильтры на те сообщения которые нужны.
Неплоха также идея предусмотреть сообщения с "оплаченным ответом" - вызовы методов.
Но вот дальше начинается мрак. Низкоуровневый API настолько сложен и развесист, что встроить его в существующий event loop - задача крайне непростая. А ведь практически все приложения, которые могут выиграть от использования DBUS какой-то event loop, скорее всего основанный на select на некотором наборе дескрипторов, уже имеют. Почему-то авторам openobex удалось организовать свою библиотеку так, чтобы делать select на обексовом сокете было удобно, а авторам DBUS - нет.
Далее, идея типизации аргументов. Похоже, на естественных языках эти люди думать не умеют, только на C. Какой смысл на уровне системной шины сообщений, вызовы методов на которой происходят не чаще, чем порождения процессов в системе, различать целые числа и строки?
Защититься от ошибок это всё равно не поможет. Гораздо более полезным было бы сопровождать значение именем параметра, а не его типом, и всё гонять как строки. Затраты на преобразования числа в строку - всё равно копейки. Типизация полезна когда мы умеем гонять по шине сложные объекты с их методами, и, самое главное, контрактами.
А тут изобрели бинарный протокол "подобный X11" и радуются. Хотя объемы данных передаваемые в X11 и в DBUS несоизмеримы. Почему-то в HTTP/AJAX которые гоняют данные не по локальному сокету, а по узким сетевым каналам, и уровень абстракции которых лишь чуточку выше X11, обошлись без бинарного протокола, а тут не сумели. Прям как фидошники (если их сравнивать с usenet).
Далее, будь я на их месте, первое что я сделал бы, это набор утилит, который позволяет полноценно пользоваться данной шиной из shell-скриптов (а также из языков программирования, для которых DBUS-биндингов ещё не написали, но с пайпами всё хорошо. В каком-нибудь Erlang с его портами это бы на всю жизнь бы осталось основным средством работы с DBUS).
Есть, конечно, dbus-send, которая для посылки сообщений почти удачна. За исключением того, что над синтаксисом командной строки надо думать, а не пихать туда какую попало сериализацию своего представления об объектах. Но вот с dbus-monitor - всё гораздо хуже. Они, блин, не догадались вписать туда setlinebuf(stdout). Поэтому если ты запустишь dbus-monitor через popen, прихода интересующего тебя сигнала будешь ждать до морковкиного заговенья.
Инструмента для реализации объектов на shell вообще не предусмотрено. Хотя, на мой взгляд, это сделать почти тривиально. Берем и смотрим в /etc/rc.d - почти готовые объекты для работы с dbus. Имеют методы start, stop, reload и т.д. А при вызове без параметров рассказывают про свой интерфейс (правда, в не слишком машинно-читаемой форме, но это поправимо. Стандартизуем как есть - при вызове с параметром Intorspect возвращать XML-описание как описано в D-BUS спецификации.).
Соответственно пишем утилиту dbus-shell-object с параметрами имя-интерфейса имя-скрипта, которая при приходе запроса на вызов метода, вызывает указанный скрипт, передавая ему первым параметром имя метода, а далее - его аргументы. Естественно, эта утилита должна поддерживать отладочный режим - валидацию результата Introspect. Ну и режим двунаправленного пайпа - на stdout пишем приходящие вызовы, со stdin читаем на них ответы. В этом режиме желателен управляемый escaping параметров, чтобы прочитанную оттуда строчку можно было прямо в eval соответствующего интерпретатора пихать.
Но почему-то по крайней мере в той версии DBUS, которая в sarge, такой хреновины нет.
Еще бы я написал утилиту dbus-sig-wait, которая просто висит и ждет определенного сигнала. А когда приходит - завершается, выдавая содержимое сигнала на stdout. Уж как её завернуть в цикл который по сигналу выполняет определенные действия - любой программист разберется.
Проблема, конечно, не в том, американский софт, финский или китайский. Проблема в том, понимает пользователь как он работает или нет.
В последнее время OpenSource, стремясь потакать привычкам пользователей (и, что самое ужасное, разработчиков), воспитанных на проприетарном софте, развивается куда-то не туда. Появляются нетривиальные API, сложные межкомпонентные взаимодействия и т.д.
Вот разбираюсь сейчас с устройством DBUS. По идее, мысль крайне здравая - создать системную шину сообщений через которую смогут эффективно общаться процессы, не имеющие общего предка. Ввести на ней стандарное иерархическое пространство имен, чтобы можно было легко настроить фильтры на те сообщения которые нужны.
Неплоха также идея предусмотреть сообщения с "оплаченным ответом" - вызовы методов.
Но вот дальше начинается мрак. Низкоуровневый API настолько сложен и развесист, что встроить его в существующий event loop - задача крайне непростая. А ведь практически все приложения, которые могут выиграть от использования DBUS какой-то event loop, скорее всего основанный на select на некотором наборе дескрипторов, уже имеют. Почему-то авторам openobex удалось организовать свою библиотеку так, чтобы делать select на обексовом сокете было удобно, а авторам DBUS - нет.
Далее, идея типизации аргументов. Похоже, на естественных языках эти люди думать не умеют, только на C. Какой смысл на уровне системной шины сообщений, вызовы методов на которой происходят не чаще, чем порождения процессов в системе, различать целые числа и строки?
Защититься от ошибок это всё равно не поможет. Гораздо более полезным было бы сопровождать значение именем параметра, а не его типом, и всё гонять как строки. Затраты на преобразования числа в строку - всё равно копейки. Типизация полезна когда мы умеем гонять по шине сложные объекты с их методами, и, самое главное, контрактами.
А тут изобрели бинарный протокол "подобный X11" и радуются. Хотя объемы данных передаваемые в X11 и в DBUS несоизмеримы. Почему-то в HTTP/AJAX которые гоняют данные не по локальному сокету, а по узким сетевым каналам, и уровень абстракции которых лишь чуточку выше X11, обошлись без бинарного протокола, а тут не сумели. Прям как фидошники (если их сравнивать с usenet).
Далее, будь я на их месте, первое что я сделал бы, это набор утилит, который позволяет полноценно пользоваться данной шиной из shell-скриптов (а также из языков программирования, для которых DBUS-биндингов ещё не написали, но с пайпами всё хорошо. В каком-нибудь Erlang с его портами это бы на всю жизнь бы осталось основным средством работы с DBUS).
Есть, конечно, dbus-send, которая для посылки сообщений почти удачна. За исключением того, что над синтаксисом командной строки надо думать, а не пихать туда какую попало сериализацию своего представления об объектах. Но вот с dbus-monitor - всё гораздо хуже. Они, блин, не догадались вписать туда setlinebuf(stdout). Поэтому если ты запустишь dbus-monitor через popen, прихода интересующего тебя сигнала будешь ждать до морковкиного заговенья.
Инструмента для реализации объектов на shell вообще не предусмотрено. Хотя, на мой взгляд, это сделать почти тривиально. Берем и смотрим в /etc/rc.d - почти готовые объекты для работы с dbus. Имеют методы start, stop, reload и т.д. А при вызове без параметров рассказывают про свой интерфейс (правда, в не слишком машинно-читаемой форме, но это поправимо. Стандартизуем как есть - при вызове с параметром Intorspect возвращать XML-описание как описано в D-BUS спецификации.).
Соответственно пишем утилиту dbus-shell-object с параметрами имя-интерфейса имя-скрипта, которая при приходе запроса на вызов метода, вызывает указанный скрипт, передавая ему первым параметром имя метода, а далее - его аргументы. Естественно, эта утилита должна поддерживать отладочный режим - валидацию результата Introspect. Ну и режим двунаправленного пайпа - на stdout пишем приходящие вызовы, со stdin читаем на них ответы. В этом режиме желателен управляемый escaping параметров, чтобы прочитанную оттуда строчку можно было прямо в eval соответствующего интерпретатора пихать.
Но почему-то по крайней мере в той версии DBUS, которая в sarge, такой хреновины нет.
Еще бы я написал утилиту dbus-sig-wait, которая просто висит и ждет определенного сигнала. А когда приходит - завершается, выдавая содержимое сигнала на stdout. Уж как её завернуть в цикл который по сигналу выполняет определенные действия - любой программист разберется.
no subject
И + GObject'ы, лезущие изо всех щелей :(
no subject
no subject