1. Desktop-демон -- работая под Desktop-user-UID -- не сможет создать unix-сокет внутри /var/run/<...>(впринцепе это не особая проблема, так как unix-socket можно создать и в ~/.local/share/<...> . но всёже факт остаётся фактом: "неопределённость в пути к демону" . но DBus полностью решает эту проблему )
2. как осуществить авторизацию подключаемого процесса к unix-socket? ограничить socket-файл через "$ chgrp <...>" ? но ведь только super-пользователь может в полной мере пользоваться "$ chgrp <...>"! однако DBus решает эту проблему
3. необходимо заново придумать протокол трансляции RPC-запроса и RPC-ответа . у каждого демона будет свой собственный RPC-протокол ?
(ктото может возьмёт себе даже стандартный XML-RPC, ктото возьмёт JSON-RPC, а ещё есть SOAP от Microsoft!.. хотя ведь и всегда можно придумать чтото своё!)
...но в DBus УЖЕ есть механизмы трансляции RPC ! что плохого что все программы будут использовать один и тотже механизим RPC-трансляции ? ведь придётся меньше писать повторяемого программного кода!
так-что DBus и тут выигрывает! :-)
[а вызовы-и-сигналы проходящие через DBus -- можно мониторить! это же здорово!]
4. DBus чуть чуть медленее чем unix-socket ? настолько сильно чтобы его не использовать?
(например мне нада перередать через DBus сообщение о том чтобы не включалась Screensaver-заставка!.. очень прям важна тут супер-скорость-для-DBus ? :-D )
((а если мне нада применить новые конфигурации сети через DBus -- то тут тоже скорость-DBus является критичным узким местом?))
# p.s.: а почему на DBus взъелась куча народу? я вообще непойму?
неужеле это произолшо из-за того что кто-то пытался собрать [экспериментальную версию] SystemD, и SystemD отказался работать из-за не самого-нового-DBus ?
