Что курили создатели dbus?

unix sockets?

IPC да, а вот RPC сложновато будет реализовать.

говорят ныне мертвый DCOP был хорош

Это который под алкоголем написали?

Ну, вперед, напиши свой велосипед :)

И что? Отлично работал, да

Так в том то и дело, что не хочу да и не осилю нормально реализовать. Хочется готового и вменяемого.

Да и dbus отлично работает

поищи, может быть более-менее вменяемые библиотеки для работы с сабжем есть

Не спорю :)

Да и dbus отлично работает

До тех пор пока не захочешь использовать его в своем приложении.

GObject

Если ты пишешь на голоС, то ты попал. Приятной копипасты :]

ясных и удобных решениях для IPC и RPC.

OSGi

Для чего нужны были отдельные bus name, object path, interface name, имена членов интерфейса?

Ты точно неосилятор, например у блютуса:

- object path - путь к объекту, т.е к адаптеру один, а девайсам которые этот адаптер нашел - дочерние пути адатера

- interface name - по сути это то что умеет приложение, тотже блютус умеет прикидыватся наушниками или устройством ввода - для это интерфейсы нужны разные

Java-only же, нет?

Я что-то не вижу причин по которым здесь нельзя было бы обойтись простой структурой в виде виртуальной файловой системы. Пример привести можешь, а то так не очень понятно?

Я что-то не вижу причин по которым здесь нельзя было бы обойтись простой структурой в виде виртуальной файловой системы

И как ты наследование через Фс изобразишь извращанец? Не если теба результат сего действа устроит, то ваяй - никаких проблем, но пользоваться этим никто не будет

нужна помощь в переписывании dbus

более других, ясных и удобных решениях для IPC и RPC

ZeroC ICE

это ты ещё corba не видел

fuse в руки и вперед

btw нагуглил тут же https://npmjs.org/package/dbusfs и таких несколько даже

fuse не переносим.

Дык делов-то, возьми 0mq к примеру, вокруг request-response накрути свой rpc. Например запакуй в структуру название метода и массив параметров. В ответ высылай структуру из флажка результата, самого результата и сообщения об ошибке. В качестве транспорта можно взять ipc, если нужно будет разнести по сети, то без проблем заменишь на tcp.

Ну и если есть желание потрахаться с промежуточным языком для представления сообщений, то есть Thrift.

это смотрел? http://www.zeromq.org

гораздо большие ограничения на то, как работает программа, нет общепринятых механизмов интроспекции и прочей инфраструктуры связанной с dbus, хотя zeromq жжот.

более других, ясных и удобных решениях для IPC и RPC.

велосипедить. но вообще проблема в том, что dbus все равно приходится использовать, для взаимодействия с системными сервисами. в основных тулкитах есть обертки. в EFL есть достаточно понятная обертка, из которой можно дергать код, если хочется обойтись без лишних зависимостей, и идиотских gobject'ов.

с какими системными сервисами? Systemd? Может ну их нахрен такие сервисы?

Enterprise, разработчики сидели и представляли как весь мир, все системы полностью перейдут на dbus.

Java-only же, нет?

Ну так тебе проект делать и запускать в продакшн? Или нет?

с какими системными сервисами? Systemd? Может ну их нахрен такие сервисы?

всякие mpris, нотификации, gnome/kde multimedia buttons, интеграция с панелькой в убунте, и т.п.

про systemd не знаю, не пользовался еще.

Если что-то есть в апстриме, это совершенно не значит что это стоит использовать. Во многих случаях (привет, consolekit) это даже в апстриме понимают (со временем, правда).

Если что-то есть в апстриме, это совершенно не значит что это стоит использовать.

ну я привел вполне конкретные примеры, где без dbus не обойтись. понятно, что есть множество примеров, когда dbus не нужен. я вообще не призываю его использовать, скорее наоборот, и вообще согласен с ТС.

Ты немного неверно меня понял — я прокомментировал «велосипедить». А так да, если хочется интеграции (а хочется ли, уже отдельный разговор) без dbus, увы, не обойтись.

тогда я вообще не понял, что вы хотели сказать.