История изменений

Я предыдущему оратору очень «тонко» намекал, что ему придётся это всё стандартизировать и унифицировать. И что здесь важен не только (и не столько) транспорт, но ещё универсальна сериализация и маршаллинг. В результате получить тотже эрзац-dbus (ну, Varlink/Binder/etc. да куча их, какой больше нравится). По вашей идее, вместо демона шиной используется ФС. Ну ок, какие из этого плюсы (ну кроме повышения уровня абстрагирования и, соответственно, куда больших тормозов, уж и DBus-то тут не подарок, хотя с брокером получше)?

Зачем? У нас же файл-сокет.

Сервер в этот сокет отправил пакет, n-цать клиентов должны его получить. Только они, не вся шина. Действия? Насилуем себя multicast-ом.

Зачем что-то кроме файла для взаимодействия внутри одного компьютера?

Да хоть пайпы, хоть shm. Сериализацию и синхронизацию это как-то отменило? А TCP потому что постоянное соединение. Клиентов всё равно предполагается не сильно много (в подавлящем большинстве один) и траффик там копеечный. Поэтому ТСР, в данном случае, «охлаждает траханье»(с) со стеком и не более.

В случае dbus она просто уже неотъемлемая часть libdbus

Ну так, а я что, возражаю чтоли? Факт, что это буду делать не я.

Без дополнительной информации не вытащить.

Но машиночитаемая информация о типах и порядке их передачи в наличии. Структура из двух uint32_t, между которыми два uint16_t и пять строк.

А почему не https://github.com/json-c/json-c ?

Там cJSON пашет. Велик для того, чтобы структуры протокола одинаково (де-)сериализовались как на клиенте, так и на сервере в нужные структуры.

И вообще, зачем json на отправку пары чисел в запросе и, фактически, списка строк в ответе?

Допустим API немного поменялся. Резко и решительно переписываем всё, что использует наш кастомный бинарный протокол? Да ну, нафиг.

Поверх JSON/DBus или поверх строк или поверх protobuf

Да хоть поверх мейл-слотов. Стандартизировать-то и унифицировать это всё равно надо. Вон в Varlink, вроде как, json и гоняется.

Ещё раз, для протокола, мне как-то всё равно, какой там высокоуровневый IPC (DBus/Varlink/Binder/etc.). Факт в том, что он должен быть. В linux на данный момет единственный - это DBus (Varlink ещё не взлетел и далеко не факт, что взлетит). А комментатор, с которым мы дискутируем, предлагает зачем-то от его отказаться и городить в каждом приложении его куски самостоятельно (даже если все на свете договоряться поддерживать хоть какой-то протокол). Зачем, мне решительно не понятно.

Я предыдущему оратору очень «тонко» намекал, что ему придётся это всё стандартизировать и унифицировать. И что здесь важен не только (и не столько) транспорт, но ещё универсальна сериализация и маршаллинг. В результате получить тотже эрзац-dbus (ну, Varlink/Binder/etc. да куча их, какой больше нравится). По вашей идее, вместо демона шиной используется ФС. Ну ок, какие из этого плюсы (ну кроме повышения уровня абстрагирования и, соответственно, куда больших тормозов, уж и DBus-то тут не подарок, хотя с брокером получше)?

Зачем? У нас же файл-сокет.

Сервер в этот сокет отправил пакет, n-цать клиентов должны его получить. Только они, не вся шина. Действия? Насилуем себя multicast-ом.

Зачем что-то кроме файла для взаимодействия внутри одного компьютера?

Да хоть пайпы, хоть shm. Сериализацию и синхронизацию это как-то отменило? А TCP потому что постоянное соединение. Клиентов всё равно предполагается не сильно много (в подавлящем большинстве один) и траффик там копеечный. Поэтому ТСР, в данном случае, «охлаждает траханье»(с) со стеком и не более.

В случае dbus она просто уже неотъемлемая часть libdbus

Ну так, а я что, возражаю чтоли? Факт, что это буду делать не я.

Без дополнительной информации не вытащить.

Но машиночитаемая информация о типах и порядке их передачи в наличии. Структура из двух uint32_t, между которыми два uint16_t и пять строк.

А почему не https://github.com/json-c/json-c ?

Там cJSON пашет. Велик для того, чтобы структуры протокола одинаково (де-)сериализовались как на клиенте, так и на сервере в нужные структуры.

И вообще, зачем json на отправку пары чисел в запросе и, фактически, списка строк в ответе?

Допустим API немного поменялся. Резко и решительно переписываем всё, что использует наш кастомный бинарный протокол? Да ну, нафиг.

Поверх JSON/DBus или поверх строк или поверх protobuf

Да хоть поверх мейл-слотов. Стандартизировать-то и унифицировать это всё равно надо. Вон в Varlink, вроде как, json и гоняется.

Ещё раз, для протокола, мне как-то всё равно, какой там высокоуровневый IPC (DBus/Varlink/Binder/etc.). Факт в том, что он должен быть. В linux на данный момет единственный - это DBus (Varlink ещё не взлетел и далеко не акт, что взлетит). А комментатор, с которым мы дискутируем, предлагает зачем-то от его отказаться и городить в каждом приложении его куски самостоятельно (даже если все на свете договоряться поддерживать хоть какой-то протокол). Зачем, мне решительно не понятно.