Использование ZeroMQ для кросс-платформенной разработки?

У нас есть большое консольное приложение в Haskell, которое мне поручено сделать кросс-платформу и добавить gui.

Требования:

Родной, как возможно, внешний вид.
Клиенты для Windows и Mac OS X, если возможно, Linux.
Для установки не требуется отдельное время выполнения.
Отсутствует необходимая сетевая связь. Код haskell имеет очень чувствительную информацию, которая не может передаваться по проводу. Это действительно единственная причина, по которой это не веб-приложение.

Теперь, настоящая причина этого вопроса - объяснить одно решение, которое я сейчас исследую, и запросить по причинам, о которых я не думаю, что это плохая идея.

Мое решение - родной gui. Winforms в Windows, Cocoa в Mac OS X и GTK/Glade на Linux, который просто обрабатывает презентацию. Затем я бы написал слой поверх кода Haskell, который превращает его в ответчика для сообщений в пользовательский интерфейс и из него с помощью ZeroMQ для обработки сообщений и, возможно, протобуфов для сериализации данных взад и вперед. Таким образом, начнется собственное приложение, которое само запустило бы демона, где происходит вся магия, и отправляйте сообщения туда и обратно.

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

Что я не задумываюсь о том, что это плохая идея?

Я, наверное, должен упомянуть, что на первый взгляд я собирался пойти с GTK на всех платформах. Проблема в том, что, пока она закрывается, и поддержка GTK и Glade для Haskell приятно работать, результат не выглядит "правильным". Он близок, но не слишком утончен в тонких способах, которые делают это решение неприемлемым для людей, которые, случается, пишут чек для этой работы.

Кроме того, проблема с несколькими платформами и, следовательно, с несколькими языками для gui не является проблемой, поэтому я не обязательно ищу другие способы решения этой проблемы, если это не упростит что-то о взаимодействии с кодом haskell.

Ответ 1

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

Я думаю, что это разумно (модель клиент/сервер, где клиент просто оказывается, является настольным приложением для рабочего стола n-feel. (У меня нет сильного взгляда о протобуфах против, например, JSON, бережливость).

Haskell zeromq привязки некоторые используют теперь тоже.

Что я не задумываюсь о том, что это плохая идея?

Насколько хорошо протестирован zeromq на Windows и Mac? Вероятно, это хорошо, но что-то я проверил.

Проблема заключается в том, что, хотя она и закрывается, и поддержка GTK и Glade для Haskell приятно работать, результат не выглядит "правильным".

Помогает ли пакет интеграции есть?

Ответ 2

Здесь интересная возможность: wai-handler-webkit. По сути, это пакет QtWebkit с веб-сервером Warp для развертывания ваших веб-приложений. Он не видел интенсивного использования, никогда не тестировался на Mac и сложно скомпилировать в Windows, но это довольно простой подход, который позволяет использовать довольно богатую веб-экосистему, развивающуюся в Haskell.

В ближайшем будущем я, вероятно, буду делать больше развития, поэтому, если у вас есть интерес к его использованию, дайте мне знать, какие дополнительные функции будут полезны, а также если вы можете предложить любую помощь на Mac фронт, в частности. Я также не убежден, что нам нужно придерживаться QtWebkit на всех платформах: возможно, имеет смысл использовать другой бэкэнд Webkit в зависимости от ОС или, возможно, вместо этого использовать Gecko или (содрогнуться) Trident.

Ответ 3

У меня были некоторые проблемы с получением zeromq, чтобы хорошо играть с haskell на OSX (проблемы с поиском dylib в отличие от "o", я думаю). Протокольные буферы и haskell, похоже, работают нормально.

Ответ 4

Итак, ваша причина не использовать веб-приложение из-за деликатного характера выхода программы haskell. И ТАК, почему вы распространяете то же самое чувствительное приложение, которое выводит незашифрованные данные на ВСЕ клиентские машины? В этом нет смысла.

Если ваше приложение чувствительно, вы DEFINITELLY должны поставить его на сервер и использовать максимально возможный TLS.