Re: Изменение раскладки при помощи hal
On Tue, 11 Aug 2009 23:45:34 +0400
Ed <spied@yandex.ru> wrote:
> Alexander Galanin wrote:
> > Вроде говорилось про "bluetooth", который в ядре. А реализован
> > bluetooth-стек в linux проектом под названием bluez, неядерная часть
> > которого иначе как через dbus общаться не умеет.
>
> во-первых userspace можно и переписать так, чтобы dbus не требовался.
Разумеется. Только сдаётся мне, что никто этого в апстрим не примет.
> а во-вторых dbus пожалуй наименьшее из зол. у него конечно есть свои
> недостатки, но:
> - dbus относительно лёгкий (скажем в maemo многое сделано на dbus - и
> нормально тот maemo работает);
Без указания, относительно чего он "лёгкий", это пустые слова.
> - во-вторых оно хоть и убого, но скриптуется;
dbus-monitor не скриптуется совершенно по причинам его реализации.
dbus-send --- отписка, сделанная только ради строки "поддерживает
скриптование". Ужасный формат, в котором оно возвращает результаты,
малопригоден для парсинга. Конечно, есть более человечный qdbus, но он
не работает, если не реализована необязательная интроспекция, да и со
сложными типами данных работать отказывается.
Реализовать же "серверную часть" ("объект на шине" в терминологии dbus)
вообще из скриптов невозможно.
> - наконец потребность в высокоуровневом стандартизованном средстве IPC
> существует. кривоватый dbus лучше, чем ничего.
То есть Вы хотите сказать, что те 30 лет существования юникса до
появления дбуса прошли без средств IPC? Смешно.
Коль скоро зашла речь о недостатках d-bus-а, распишу поподробнее:
1. В высшей степени странный дизайн, когда смешивают в одном передачу
нотификаций о событиях и удалённый вызов методов.
2. Всё общение ведётся через один сокет (к слову, не обязательно
юниксовый). В результате чего вылезает проблема разделения прав
доступа, которая не может быть в таком виде решена средствами unix, в
результате чего приходится городить костыль policykit. А, казалось бы,
решение лежит на поверхности: разнести точки связи в разные сокеты и
приписать им соответствующие права.
3. Прикручивание объектной модели там, где это совершенно не нужно.
Причём такой, которая ещё не на всякий язык нормально ляжет.
4. Как следствие предыдущего пункта, странная адресация: для того,
чтобы вызвать всего один метод, надо туняться к нему, указывая путь к
объекту, интерфейс и имя, вместо того, чтобы указывать только имя.
5. Типизация. Нафига, спрашивается? Не 20 век на дворе, чтобы в
высокоуровневом протоколе типы указывать.
6. Нет понятия "сессия".
7. В результате сложности формата есть только одна рабочая реализация:
libdbus. Соответственно, все баги в ней оказываются багами всех
приложений сразу.
8. Сложности с встраиванием в очередь сообщений произвольной
библиотеки. По факту, все имеющиеся сегодня в дистрибутиве программы
используют glib event loop, потому что libdbus писалась под него.
9. Интроспекция не является обязательной.
10. Подозреваю, что мало кто из клиентов проверяет sender-а в ответах
или сообщениях об ошибках. Что может привести к тому, что ответ по шине
может придти от совершенно постороннего приложения.
--
Alexander Galanin
http://galanin.nnov.ru
Reply to: