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

Question

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

Требования:

1. Собственный внешний вид, как это возможнои чувствовать.
2. Клиенты для Windows и Mac OS X, Linux, если это возможно.
3. Нет отдельной среды выполнения для установки.
4. Нет необходимости сетевого взаимодействия.Код haskell имеет дело с очень чувствительной информацией, которая не может быть передана по проводам.Это действительно единственная причина, по которой это не веб-приложение.

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

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

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

О чем я не думаючто делает это плохой идеей?

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

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

Answer 1

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

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

Привязки Haskell zeromq тоже находят некоторое применение сейчас.Я не задумываюсь над тем, что делает это плохой идеей?

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

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

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

Answer 2

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

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

Answer 3

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

Answer 4

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

Если ваше приложение чувствительно, вы ОБЯЗАТЕЛЬНО должны поместить его на сервер и использовать максимально возможную TLS .