Russian Qt Forum

Привет всем. Возник такой вопрос.
Необходимо реализовать интерфейс для взаимодействия с другими программами (т.е. другие программы смогут использовать функционал моей программы). В Linux это можно сделать посредством dbus. Есть ли кроссплатформенный инструмент или придется пилить реализацию для каждой операционки отдельно? Если нет, какие инструменты посоветуете для linux, windows, mac os?

Если функции программа предоставляет интерфейс не имеющий состояний, то реализуете каждую функцию (или набор функций) в виде программы принимающей аргументы командной строки, с возвратом значения в stdout, ошибок в stderr.
А далее можно подумать и управление программой осуществлять через stdin, а не аргументами командной строки. Это значит, что Ваша задача сводится к написанию некоторого telnet сервера, которыми оснащаются сетевые устройства например. Автоматизированное управление данным сервером можно осуществлять сценариями командной строки клиентской операционной системы.
Впринципе крассплатформенность/сетевая прозрачность обеспечена. Защита передаваемых данных с помощью ssh.

Pipe - QLocalServer, QLocalSocket; QSharedMemory

Многое зависит от того должны ли 32 и 64-битные приложения общаться между собой. Если все "только 32" (или только 64), то просто dll (dylib). Если же "смешанный" вариант, то сложнее - либо на сокетах, либо (если нужна скорость) на семафорах и shared memory

А можно поподробнее об этом? О таком я ещё не слышал

Если это вопрос ко мне и по поводу 32/64 - то использовать dll (приятные во всех отношениях) не удается т.к. на любой платформе 32 хост не может звать 64 dll и наоборот. Простейший вариант для 2 приложений (32 и 64) - создать 2 shared семафора. Каждое приложение ждет на одном (возможно 1 ниткой) и сигналит по другому. Как только сигнал получен - данные забираются из shared memory.

Вопрос наверно немного не в тему. Но все же, подскажите как объединить вывод в file и stderr на консоль?

Если клиенты планируются только кутешные, то можно воспользоваться либой QXT. в ней реализован RPC протокол на основе механизма сигналов/слотов. там фактически сигнал передается другому процессу через QIODevice.
Для отвязки клиентов от Qt можно реализовать свой небольшой RPC сервис. я делал на базе Hessian.

В свое время для реализации общения демона с ГУИ использовал RPC вот отсюда http://deltavsoft.com/w/ довольно удобно, но придется еще и boost к проекту подключать. Сам не в курсе ,но интересно ,а QtDBus не подойдет ?

Нет, в винде с ним проблемы. ИМХО, проще QLocalSocket/Server (как выше советовали).

Делал подобное. Использовал UDP (Изначально не хотел привязываться к TCP)
В моем обмене нет больших объемов передаваемых данных. Ставка делалась на скорость (устройства используют GPRS).  Все данные перед отправкой сжимаются в qcompress. На принимающей стороне qUncompress.
Результатом доволен.

Забыл добавить: 
При отладке механизма обмена на локальной машине отметил, что такая методика оказалась удобной и для обмена командами/данными для межпроцессного взаимодействия (если убрать функционал сжатия трафика).

Думаю если ещё и архивировать данные, это будет накладно. Да если просто команды то лучше не компресить их, а отправлять так как есть.

Безусловно!  Один 1-8 байт нет смысла сжимать. А вот 0,5 - 64 кб уже смысл есть, тем более если команды и данные передаются в ASCII символах.