> Надо же какой ты умный, без dbus то инженеры за десятилетя развития
> айти индустрии так и не придумали как решать подобные проблемы.Покажи решения. Есть пара проприетарин, гоняющих данные аж на ремотные сервера (долой приваси и не работает без интернета, что очень в духе гугли) или просто 1 проприетарный движок прибитый гвоздями - можно вот так и более вообще совсем никак.
> через такое же библиотечное api из которого ничего не видно (где
> вообше такой сценарий допустим).
Это тоже вариант, но в упомянутом случае может требоваться и мультикаст и работа с разными источниками и шина смотрится не так уж странно.
> лет успешно им всюду пользуются.
И где примеры успешного использования?
> Если даже запилить это гогнецо через dbus, то приложения не будут использовать
> его прямо через сообщения, вместо будут дёргать некую обёрточную библиотеку
А зачем? Потребуется лишь некий минимальный коннектор который адаптирует то что там внутри движка к шине. И все. Было бы довольно логично вроде.
> которая будет решать как именно нужно достучаться до сервиса - dbus, unix
> сокет, прямое использование библиотеки и ещё что.
В принципе тоже вариант. Но с шиной больше разных вариантов с множественными подписчиками или источниками сигнала и это бы делалось попроще в ряде случаев. Грубо говоря, если я дергаю либу а там кто-то уже синтезатором спича трындит - это довольно отдельный случай. В этом случае они или все-равно будут городить шинообразную очередизацию и прочее и получится куча подобного кода но в какой-то либе, а потом в другой либе еще куча такого же кода, или оно будет работать как г-но. Тогда как 1 раз сделать быструю шину с приоритетами и прочим - проще чем все это же но в 20 разных закоулках.
> Это чушь от дилетанта, даже близко не угадал зачем может понадобиться пользоваться
> dbus подобной технологией.
На самом деле много зачем. А этот пример несколько натянутый но - вполне себе вариант зачем там аудио протолкать может захотеться.
