Использование 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.